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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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

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