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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On mar, 2013-11-05 at 15:11 +0000, George Dunlap wrote:
> On 11/05/2013 03:03 PM, George Dunlap wrote:
> > On 11/05/2013 02:52 PM, Jan Beulich wrote:
> >>>>> On 05.11.13 at 15:35, Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> >>>>> 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"?
> 
> Sorry, speaking before I had thought it through.  Of course we need a 
> numa affinity for the domain for allocating memory.
> 
Ah! And I'm also sorry I missed this one before replying! :-P

> How about, "cpu_node_affinity"?
> 
> Or, we could internally change the names to "cpu_hard_affinity" and 
> "cpu_soft_affinity", since that's effectively what the scheduler will 
> do.  It's possible someone might want to set soft affinities for some 
> other reason besides NUMA performance.
> 
That sounds reasonable to me, as far as we are aware that the upper
layer would continue to call "hard affinity" as either "vcpu
affinity" (domctl_, libxc and libxl) or "vcpu pinning" (xl, command name
is 'vcpu-pin'). For the "soft affinity", I think the term "node
affinity" or "NUMA node affinity" already spread a little bit around the
codebase, so even if there is no real libxc or libxl interface for that
before this patch, we may have to live with that too.

Is this acceptable?

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: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel