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: 2277 bytes --]

On mar, 2013-11-05 at 15:11 +0000, Jan Beulich wrote:
> >>> On 05.11.13 at 16:03, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> > On 11/05/2013 02:52 PM, Jan Beulich wrote:
> >>>>> On 05.11.13 at 15:35, Dario Faggioli <dario.faggioli@citrix.com> wrote:
> >>> @@ -197,6 +199,13 @@ struct vcpu
> >>>       /* Used to restore affinity across S3. */
> >>>       cpumask_var_t    cpu_affinity_saved;
> >>>
> >>> +    /*
> >>> +     * Bitmask of CPUs on which this VCPU prefers to run. For both this
> >>> +     * and auto_node_affinity access is serialized against
> >>> +     * v->domain->node_affinity_lock.
> >>> +     */
> >>> +    cpumask_var_t    node_affinity;
> >>
> >> This all looks quite sensible, except for the naming here: We
> >> already have a node_affinity field in struct domain, having a
> >> meaning that one can expect with this name. So you break
> >> both consistency and the rule of least surprise here. How
> >> about just "preferred_cpus"?
> > 
> > Actually, would it make more sense to remove node_affinity from the 
> > domain struct, and have the tools manually set the node_affinity for the 
> > various vcpus if the user attempts to set the "domain numa affinity"?
> 
> Quite likely, yes. But that doesn't mean that the name can be kept
> as is.
> 
Not really. Well, it sure is possible, but it's a bit more involved than
it sounds, as the node_affinity field in struct domain drives all the
actual memory allocations, and it's maintained in a nodemask_t as that's
easier to use in that circumstance.

Getting rid of it would mean going through the node_affinity of all
vcpus and build such node mask all the times (or something like that),
which I think is both more code and less performance! :-P
(BTW, seeing the rest of the e-mails, I think you ended up realizing
that, but still...)

So, as I'll say replying to the other messages, I'm fine with changing
names, much less with removing d->node_affinity.

Thanks and 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