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:11 PM, Jan Beulich wrote:
> > > > On 05.11.13 at 16:03, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 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"?
> Quite likely, yes. But that doesn't mean that the name can be kept
> as is.
Right, I see what you're saying -- in the domain struct, node_affinity 
is a mask of nodes, but here it's being used as a mask of cpus.  Yes, 
that needs to change.
 -George

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