[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


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Thu, 28 Apr 2011 11:08:40 +0100
  • Cc: george.dunlap@xxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxx>
  • Delivery-date: Thu, 28 Apr 2011 03:09:35 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OlSDPgn6sYZO9cd6QurXyjEztumc0rTvWYjNlE2cBCF1HaBbtg/6AV4PeScgNf6Xii hPklNoTL9pta6MJ6VGgi2hN765VCkvDqLlR1yWDL8ZLR90QMC5HWXfjQK6cYjtlAhmXB +Eki8HzOCOlYmJm3wx/dkXnlgTdv7MedPiuKU=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.