WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] credit2: add a callback to migrate to a new cpu

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] credit2: add a callback to migrate to a new cpu
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zf/H1v5Hx6rvA77miYvUO8aBjJV77Yj7V5xMECe/vCA=; b=J23i/E0SUt9kQGSITeO2k5Uzj/8B0HuMrm44F5h1rOi+zImkz0opshv9uzWgdKgnyQ jmVc5xulpT0WcnwtADwaTuyqcpDG2nwjtMCg2RQIYUa+nA6nLbXs7/MH2HqlKzIADgMl taCM+2vQjEn2X88yX/qaS+nPk6O+pBa1CfTPc=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <83859d845ef5d35309b7.1303837548@elijah>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <83859d845ef5d35309b7.1303837548@elijah>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>