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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2483 bytes --]

On mer, 2013-11-06 at 09:46 +0000, Jan Beulich wrote:
> >>> On 06.11.13 at 10:39, Dario Faggioli <dario.faggioli@citrix.com> 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").

Regards,
Dario

-- 
<<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 #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