[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Xen sched: Fix multiple runqueues in credit2

On gio, 2014-02-06 at 10:13 +0100, Juergen Gross wrote:
> On 06.02.2014 09:58, Justin Weaver wrote:
> > This patch attempts to address the issue of the Xen Credit 2
> > Scheduler only creating one vCPU run queue on multiple physical
> > processor systems. It should be creating one run queue per
> > physical processor.
> >
> > CPU 0 does not get a starting callback, so it is hard coded to run
> > queue 0. At the time this happens, socket information is not
> > available for CPU 0.
> >
> > Socket information is available for each individual CPU when each
> > gets the STARTING callback (I believe socket information is also
> > available for CPU 0 by that time). This patch adds the following
> > algorithm...
> >
> > IF cpu is on the same socket as CPU 0, add it to run queue 0
> You should check whether cpu and CPU0 are in the same cpupool.
> BTW: CPU0 is allowed to be moved to another cpupool, too.
Good points. However, the code, as it is now, does not look to care much
about cpupools while constructing this 'one runqueue per socket' thing,
does it? I mean, what happens, right now, if, either after or credit2
builds up the runqueues --say one per socket-- two pCPUs from the same
socket are in different cpupools? It looks to me that things are
considered orthogonal while, as you say, tthy may not be... I guess I'll
try that ASAP and let you know...

My point being that, Justing is trying to fix a bug in credit2, which
says it constructs one runqueue per socket, while it ends up with only
one runqueue at all. If there is another bug, or buggy behavior, wrt how
this interacts with cpupools, although we should fix that too, that's
pre-existent and needs addressing in a dedicated patch (series), isn't

Thanks and Regards,

<<This happens because I choose it to happen!>> (Raistlin Majere)
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list



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