[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 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.