[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
- To: Jan Beulich <JBeulich@xxxxxxxx>
- From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
- Date: Tue, 5 Nov 2013 15:03:14 +0000
- Cc: Marcus Granado <Marcus.Granado@xxxxxxxxxxxxx>, Justin Weaver <jtweaver@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Li Yechen <lccycc123@xxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Dario Faggioli <dario.faggioli@xxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Matt Wilson <msw@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, Elena Ufimtseva <ufimtseva@xxxxxxxxx>, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
- Delivery-date: Tue, 05 Nov 2013 15:03:31 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
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"?
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
