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

Re: [Xen-devel] [PATCH RESEND 05/12] xen: numa-sched: make space for per-vcpu node-affinity

On mer, 2013-11-06 at 09:46 +0000, Jan Beulich wrote:
> >>> On 06.11.13 at 10:39, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> > Now, we're talking about killing vc->cpu_affinity and not introducing
> > vc->node_affinity and, instead, introduce vc->cpu_hard_affinity and
> > vc->cpu_soft_affinity and, more important, not to link any of the above
> > to d->node_affinity. That means all the above operations _will_NOT_
> > automatically affect d->node_affinity any longer, at least from the
> > hypervisor (and, most likely, libxc) perspective. OTOH, I'm almost sure
> > that I can force libxl (and xl) to retain the exact same behaviour it is
> > exposing to the user (just by adding an extra call when needed).
> > 
> > So, although all this won't be an issue for xl and libxl consumers (or,
> > at least, that's my goal), it will change how the hypervisor used to
> > behave in all those situations. This means that xl and libxl users will
> > see no change, while folks issuing hypercalls and/or libxc calls will.
> > 
> > Is that ok? I mean, I know there are no stability concerns for those
> > APIs, but still, is that an acceptable change?
> I would think that as long as d->node_affinity is empty, it should
> still be set based on all vCPU-s' hard affinities 
I see, and that sounds sensible to me... It's mostly a matter a matter
of deciding whether o not we want something like that, and, if yes,
whether we want it based on hard of soft.

Personally, I think I agree with you on having it based on hard
affinities by default.

Let's see if George get to say something before I get to that part of
the (re)implementation. :-)

> (as it is an error -
> possibly to be interpret as "do this for me" to try to set an empty
> node affinity there's no conflict here). Or alternatively a flag
> could be set once it got set, preventing further implicit updates.
Sure. It's actually quite similar to that already. Both in the tree and
in the series, affinity to none is just error, affinity to all means "do
it for me", and I do have the flag there. I can easily change this into
what you're suggesting (i.e., make none => "do it for me").


<<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®.