All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir (Xen.org)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 1 of 6 v2] xen: sched_credit: improve picking up the idlal CPU for a VCPU
Date: Fri, 14 Dec 2012 19:16:27 +0000	[thread overview]
Message-ID: <50CB7B0B.9010605@eu.citrix.com> (raw)
In-Reply-To: <bced65aa4410b0272064.1355280771@Solace>

On 12/12/12 02:52, Dario Faggioli wrote:
> In _csched_cpu_pick() we try to select the best possible CPU for
> running a VCPU, considering the characteristics of the underlying
> hardware (i.e., how many threads, core, sockets, and how busy they
> are). What we want is "the idle execution vehicle with the most
> idling neighbours in its grouping".
>
> In order to achieve it, we select a CPU from the VCPU's affinity,
> giving preference to its current processor if possible, as the basis
> for the comparison with all the other CPUs. Problem is, to discount
> the VCPU itself when computing this "idleness" (in an attempt to be
> fair wrt its current processor), we arbitrarily and unconditionally
> consider that selected CPU as idle, even when it is not the case,
> for instance:
>   1. If the CPU is not the one where the VCPU is running (perhaps due
>      to the affinity being changed);
>   2. The CPU is where the VCPU is running, but it has other VCPUs in
>      its runq, so it won't go idle even if the VCPU in question goes.

Good catch -- thanks.  Comments below.

> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -59,6 +59,8 @@
>   #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
>   #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
>   #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
> +/* Is the first element of _cpu's runq its idle vcpu? */
> +#define IS_RUNQ_IDLE(_cpu)  (is_idle_vcpu(__runq_elem(RUNQ(_cpu)->next)->vcpu))
>   
>   
>   /*
> @@ -479,9 +481,14 @@ static int
>        * distinct cores first and guarantees we don't do something stupid
>        * like run two VCPUs on co-hyperthreads while there are idle cores
>        * or sockets.
> +     *
> +     * Notice that, when computing the "idleness" of cpu, we may want to
> +     * discount vc. That is, iff vc is the currently running and the only
> +     * runnable vcpu on cpu, we add cpu to the idlers.
>        */
>       cpumask_and(&idlers, &cpu_online_map, CSCHED_PRIV(ops)->idlers);
> -    cpumask_set_cpu(cpu, &idlers);
> +    if ( current_on_cpu(cpu) == vc && IS_RUNQ_IDLE(cpu) )
> +        cpumask_set_cpu(cpu, &idlers);

Why bother with this whole "current_on_cpu()" thing, when you can just 
look at vc->processor?  I.e.:

if ( cpu == vc->processor && IS_RUNQ_IDLE(cpu) )

>       cpumask_and(&cpus, &cpus, &idlers);
>       cpumask_clear_cpu(cpu, &cpus);
>   
> @@ -489,7 +496,7 @@ static int
>       {
>           cpumask_t cpu_idlers;
>           cpumask_t nxt_idlers;
> -        int nxt, weight_cpu, weight_nxt;
> +        int nxt, nr_idlers_cpu, nr_idlers_nxt;

I think Jan is right, this probably should be a separate patch.

  -George

  parent reply	other threads:[~2012-12-14 19:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12  2:52 [PATCH 0 of 6 v2] xen: sched_credit: fix picking & tickling and also add some tracing Dario Faggioli
2012-12-12  2:52 ` [PATCH 1 of 6 v2] xen: sched_credit: improve picking up the idlal CPU for a VCPU Dario Faggioli
2012-12-12 10:04   ` Jan Beulich
2012-12-12 10:19     ` Dario Faggioli
2012-12-12 10:30       ` Jan Beulich
2012-12-12 10:38         ` Dario Faggioli
2012-12-14 19:50     ` George Dunlap
2012-12-17  8:35       ` Jan Beulich
2012-12-17 14:36         ` Dario Faggioli
2012-12-14 19:16   ` George Dunlap [this message]
2012-12-12  2:52 ` [PATCH 2 of 6 v2] xen: sched_credit: improve tickling of idle CPUs Dario Faggioli
2012-12-14 19:29   ` George Dunlap
2012-12-12  2:52 ` [PATCH 3 of 6 v2] xen: sched_credit: use current_on_cpu() when appropriate Dario Faggioli
2012-12-14 19:39   ` George Dunlap
2012-12-17 14:41     ` Dario Faggioli
2012-12-12  2:52 ` [PATCH 4 of 6 v2] xen: tracing: report where a VCPU wakes up Dario Faggioli
2012-12-14 19:57   ` George Dunlap
2012-12-17 14:43     ` Dario Faggioli
2012-12-12  2:52 ` [PATCH 5 of 6 v2] xen: tracing: introduce per-scheduler trace event IDs Dario Faggioli
2012-12-14 20:00   ` George Dunlap
2012-12-12  2:52 ` [PATCH 6 of 6 v2] xen: sched_credit: add some tracing Dario Faggioli
2012-12-14 20:05   ` George Dunlap
2012-12-17 14:45     ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50CB7B0B.9010605@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.