[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1441373702-31796-2-git-send-email-daniel.wagner@bmw-carit.de>
Date: Fri, 4 Sep 2015 15:34:54 +0200
From: Daniel Wagner <daniel.wagner@...-carit.de>
To: linux-kernel@...r.kernel.org
Cc: Daniel Wagner <daniel.wagner@...-carit.de>,
"H. Peter Anvin" <hpa@...or.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Chris Metcalf <cmetcalf@...hip.com>,
David Vrabel <david.vrabel@...rix.com>,
Ingo Molnar <mingo@...hat.com>,
John Hubbard <jhubbard@...dia.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Lai Jiangshan <laijs@...fujitsu.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
xen-devel@...ts.xenproject.org
Subject: [RFC v0 1/9] smpboot: Add a separate CPU state when a surviving CPU times out
The CPU_DEAD_FROZEN state is abused to report to cpu_wait_death() that
the operation timeout. It has nothing to do with the pm freezing
process. Introduce a new state to allow proper distinction between the
states and also prepares the code to get rid of all FROZEN states.
This was intruced in
8038dad7e888581266c76df15d70ca457a3c5910 smpboot: Add common code for notification from dying CPU
2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 x86: Use common outgoing-CPU-notification code
Signed-off-by: Daniel Wagner <daniel.wagner@...-carit.de>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: Chris Metcalf <cmetcalf@...hip.com>
Cc: David Vrabel <david.vrabel@...rix.com>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: John Hubbard <jhubbard@...dia.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: x86@...nel.org
Cc: xen-devel@...ts.xenproject.org
Cc: linux-kernel@...r.kernel.org
---
arch/x86/xen/smp.c | 2 +-
include/linux/cpu.h | 2 ++
kernel/smpboot.c | 4 ++--
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 8648438..7a8bc03 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -740,7 +740,7 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct task_struct *tidle)
* This can happen if CPU was offlined earlier and
* offlining timed out in common_cpu_die().
*/
- if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+ if (cpu_report_state(cpu) == CPU_DEAD_TIMEOUT) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
}
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 23c30bd..381ea8a 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -101,6 +101,8 @@ enum {
* idle loop. */
#define CPU_BROKEN 0x000C /* CPU (unsigned)v did not die properly,
* perhaps due to preemption. */
+#define CPU_DEAD_TIMEOUT 0x000D /* CPU (unsigned)v surviving CPU timed
+ out */
/* Used for CPU hotplug events occurring while tasks are frozen due to a suspend
* operation in progress
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 7c434c3..e37efbf 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -505,7 +505,7 @@ update_state:
* Called by the outgoing CPU to report its successful death. Return
* false if this report follows the surviving CPU's timing out.
*
- * A separate "CPU_DEAD_FROZEN" is used when the surviving CPU
+ * A separate "CPU_DEAD_TIMEOUT" is used when the surviving CPU
* timed out. This approach allows architectures to omit calls to
* cpu_check_up_prepare() and cpu_set_state_online() without defeating
* the next cpu_wait_death()'s polling loop.
@@ -521,7 +521,7 @@ bool cpu_report_death(void)
if (oldstate != CPU_BROKEN)
newstate = CPU_DEAD;
else
- newstate = CPU_DEAD_FROZEN;
+ newstate = CPU_DEAD_TIMEOUT;
} while (atomic_cmpxchg(&per_cpu(cpu_hotplug_state, cpu),
oldstate, newstate) != oldstate);
return newstate == CPU_DEAD;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists