From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: About vcpu wakeup and runq tickling in credit
Date: Thu, 15 Nov 2012 16:50:06 +0100 [thread overview]
Message-ID: <1352994606.5351.54.camel@Solace> (raw)
In-Reply-To: <50A4DD95.5020107@eu.citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1489 bytes --]
On Thu, 2012-11-15 at 12:18 +0000, George Dunlap wrote:
> > So, in the vcpu-affinity case, if pcpu 3 get tickled, when it peeks at
> > pcpu 13's runq for work to steal it does not find anything suitable and
> > give up, leaving d51v1 in the runq even if there are idle pcpus on which
> > it could run, which is already bad.
> > In the node-affinity case, pcpu 3 will actually manage in stealing d51v1
> > and running it, even if there are idle pcpus with which it has
> > node-affinity, and thus defeating most of the benefits of the whole NUMA
> > aware scheduling thing (at least for some workloads).
>
> Maybe what we should do is do the wake-up based on who is likely to run
> on the current cpu: i.e., if "current" is likely to be pre-empted, look
> at idlers based on "current"'s mask; if "new" is likely to be put on the
> queue, look at idlers based on "new"'s mask.
>
EhEh, if you check the whole thread, you'll find evidence that I
thought this to be a good idea from the very beginning. I've already a
patch for that, just let me see if numbers (with and without NUMA
scheduling) are aligned with impressions and then I'll send everything
together.
Thanks for your time,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-11-15 15:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 13:34 About vcpu wakeup and runq tickling in credit Dario Faggioli
2012-10-23 15:16 ` George Dunlap
2012-10-24 16:48 ` Dario Faggioli
2012-11-15 12:10 ` Dario Faggioli
2012-11-15 12:18 ` George Dunlap
2012-11-15 15:50 ` Dario Faggioli [this message]
2012-11-16 10:53 ` Dario Faggioli
2012-11-16 12:00 ` Dario Faggioli
2012-11-16 15:44 ` George Dunlap
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=1352994606.5351.54.camel@Solace \
--to=raistlin@linux.it \
--cc=JBeulich@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=keir.xen@gmail.com \
--cc=xen-devel@lists.xen.org \
/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.