[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] credit2: add a callback to migrate to a new cpu
This bug is present in 4.1 as well; this patch will apply and build cleanly if c/s 22982:591c459ee00a is included as well. -George On Tue, Apr 26, 2011 at 6:05 PM, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote: > In credit2, there needs to be a strong correlation between > v->processor and the runqueue to which a vcpu is assigned; > much of the code relies on this invariant. Allow credit2 > to manage the actual migration itself. > > This fixes the most recent credit2 bug reported on the list > (Xen BUG at sched_credit2.c:1606) in Xen 4.1, as well as > the bug at sched_credit2.c:811 in -unstable (which catches the > same condition earlier). > > Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> > > diff -r 80401982465d -r 83859d845ef5 xen/common/sched_credit2.c > --- a/xen/common/sched_credit2.c Mon Apr 25 13:17:05 2011 +0100 > +++ b/xen/common/sched_credit2.c Tue Apr 26 18:03:32 2011 +0100 > @@ -1352,32 +1352,28 @@ > static int > csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc) > { > - struct csched_vcpu * const svc = CSCHED_VCPU(vc); > int new_cpu; > > - /* The scheduler interface doesn't have an explicit mechanism to > - * involve the choosable scheduler in the migrate process, so we > - * infer that a change may happen by the call to cpu_pick, and > - * remove it from the old runqueue while the lock for the old > - * runqueue is held. It can't be actively waiting to run. It > - * will be added to the new runqueue when it next wakes. > - * > - * If we want to be able to call pick() separately, we need to add > - * a mechansim to remove a vcpu from an old processor / runqueue > - * before releasing the lock. */ > - BUG_ON(__vcpu_on_runq(svc)); > - > new_cpu = choose_cpu(ops, vc); > - /* If we're suggesting moving to a different runqueue, remove it > - * from the old runqueue while we have the lock. It will be added > - * to the new one when it wakes. */ > - if ( svc->rqd != NULL > - && RQD(ops, new_cpu) != svc->rqd ) > - runq_deassign(ops, vc); > > return new_cpu; > } > > +static void > +csched_vcpu_migrate(const struct scheduler *ops, struct vcpu *vc, int > new_cpu) > +{ > + struct csched_vcpu * const svc = CSCHED_VCPU(vc); > + struct csched_runqueue_data *trqd; > + > + /* Check if new_cpu is valid */ > + BUG_ON(!cpu_isset(new_cpu, CSCHED_PRIV(ops)->initialized)); > + > + trqd = RQD(ops, new_cpu); > + > + if ( trqd != svc->rqd ) > + migrate(ops, svc, trqd, NOW()); > +} > + > static int > csched_dom_cntl( > const struct scheduler *ops, > @@ -2121,6 +2117,7 @@ > .adjust = csched_dom_cntl, > > .pick_cpu = csched_cpu_pick, > + .migrate = csched_vcpu_migrate, > .do_schedule = csched_schedule, > .context_saved = csched_context_saved, > > diff -r 80401982465d -r 83859d845ef5 xen/common/schedule.c > --- a/xen/common/schedule.c Mon Apr 25 13:17:05 2011 +0100 > +++ b/xen/common/schedule.c Tue Apr 26 18:03:32 2011 +0100 > @@ -489,7 +489,11 @@ > * Switch to new CPU, then unlock new and old CPU. This is safe because > * the lock pointer cant' change while the current lock is held. > */ > - v->processor = new_cpu; > + if ( VCPU2OP(v)->migrate ) > + SCHED_OP(VCPU2OP(v), migrate, v, new_cpu); > + else > + v->processor = new_cpu; > + > > if ( old_lock != new_lock ) > spin_unlock(new_lock); > diff -r 80401982465d -r 83859d845ef5 xen/include/xen/sched-if.h > --- a/xen/include/xen/sched-if.h Mon Apr 25 13:17:05 2011 +0100 > +++ b/xen/include/xen/sched-if.h Tue Apr 26 18:03:32 2011 +0100 > @@ -170,6 +170,7 @@ > bool_t tasklet_work_scheduled); > > int (*pick_cpu) (const struct scheduler *, struct vcpu *); > + void (*migrate) (const struct scheduler *, struct vcpu *, > int); > int (*adjust) (const struct scheduler *, struct domain *, > struct xen_domctl_scheduler_op *); > int (*adjust_global) (const struct scheduler *, > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |