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
|
Home