[PATCH] xen: avoid updating node affinity twice when removing a CPU from a cpupool

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2231 bytes --]

On Wed, 2015-03-11 at 16:04 +0000, Dario Faggioli wrote:
> On Wed, 2015-03-11 at 15:01 +0000, George Dunlap wrote:

> > It looks like domain_update_node_affinity() is already called for each
> > domain in the cpupool in cpu_disable_scheduler().  It doesn't look like
> > there should be a need to call it twice.  Can we just remove the call to
> > domain_update_node_affinity() in cpupool_unassign_cpu() and not add it back?
> > 
> Mmm.. true, actually.
> 
> I'll send a patch to that effect.
> 
Patch below, and attached. However, I think the correct thing to do
would be to just revert 93be8285 "update domU's node-affinity on the
cpupool_unassign_cpu() path", wouldn't it?

Regards,
Dario

8-------------------------------------------------------------------
xen: avoid updating node affinity twice when removing a CPU from a cpupool

93be8285 ("update domU's node-affinity on the cpupool_unassign_cpu()
path") introduced a call to domain_update_node_affinity() when a
pCPU is removed from a cpupool, but that happens already, in
cpu_disable_scheduler().

Furthermore, it causes (although only in rather awkward
circumstances), the following ASSERT to trigger:

(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion '!cpumask_empty(dom_cpumask)' failed at domain.c:460
(XEN) ****************************************

This change, therefore, undo that.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index a758a8b..cd6aab9 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -379,12 +379,6 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
     atomic_inc(&c->refcnt);
     cpupool_cpu_moving = c;
     cpumask_clear_cpu(cpu, c->cpu_valid);
-
-    rcu_read_lock(&domlist_read_lock);
-    for_each_domain_in_cpupool(d, c)
-        domain_update_node_affinity(d);
-    rcu_read_unlock(&domlist_read_lock);
-
     spin_unlock(&cpupool_lock);
 
     work_cpu = smp_processor_id();

[-- Attachment #1.1.2: xen-fix-cpupool-unassign-cpu.patch --]
[-- Type: text/x-patch, Size: 1409 bytes --]

xen: avoid updating node affinity twice when removing a CPU from a cpupool

93be8285 ("update domU's node-affinity on the cpupool_unassign_cpu()
path") introduced a call to domain_update_node_affinity() when a
pCPU is removed from a cpupool, but that happens already, in
cpu_disable_scheduler().

Furthermore, it causes (although only in rather awkward
circumstances), the following ASSERT to trigger:

(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion '!cpumask_empty(dom_cpumask)' failed at domain.c:460
(XEN) ****************************************

This change, therefore, undo that.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>

diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index a758a8b..cd6aab9 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -379,12 +379,6 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
     atomic_inc(&c->refcnt);
     cpupool_cpu_moving = c;
     cpumask_clear_cpu(cpu, c->cpu_valid);
-
-    rcu_read_lock(&domlist_read_lock);
-    for_each_domain_in_cpupool(d, c)
-        domain_update_node_affinity(d);
-    rcu_read_unlock(&domlist_read_lock);
-
     spin_unlock(&cpupool_lock);
 
     work_cpu = smp_processor_id();

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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