[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"). 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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |