From: Ashok Raj <ashok.raj@intel.com>
To: ak@muc.de, akpm@osdl.org
Cc: zwane@arm.linux.org.uk, rusty@rustycorp.com.au, vatsa@in.ibm.com,
shaohua.li@intel.com, linux-kernel@vger.kernel.org,
discuss@x86-64.org, ashok.raj@intel.com
Subject: [patch 4/4] CPU Hotplug support for X86_64
Date: Tue, 24 May 2005 00:27:53 -0700 [thread overview]
Message-ID: <20050524080801.185401000@csdlinux-2.jf.intel.com> (raw)
In-Reply-To: 20050524075201.351504000@csdlinux-2.jf.intel.com
[-- Attachment #1: fix_ipi_race_in_cpuhotplug.patch --]
[-- Type: text/plain, Size: 3260 bytes --]
Subject: [patch 4/4] x86_64: Replace IPI Broadcast when using CPU hotplug.
From: Ashok Raj <ashok.raj@intel.com>
This patch tries to eliminate a race condition with IPI broadcast and
CPU hotplug. Since when we broadcast we dont have control on what cpus
see a spurious intr, or possiblity of receiving an intr when the cpu is
just in process of comming up, we choose to send targetted IPI only to online
cpus.
This same workaround could be done in other places too, like genapic
locations, but this is a simpler change done here.
for the time being: we do the send_IPI_mask() version if CPU hotplug is
selected by default.
Use both CONFIG option if CPU_HOTPLUG is selected, and a cmdline option
to turn it on during startup if necessary.
1. Bringup cpu in complete cli state, and also hold call_lock when we
update online_map. (Not sure if the IPI would be pended and delivered
later causing trouble)
2. SledgeHammer approach to use stop_machine() to achive automicity.
*Very Undesirable*
3. May be setup intr_gate a little later just before setting online_map.
[still ugly bandaid, but may work] online_map should still be updated
under call_lock for safety.
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
--------------------------------------
Kconfig | 4 ++++
kernel/smp.c | 24 +++++++++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
Index: linux-2.6.12-rc4-mm2/arch/x86_64/kernel/smp.c
===================================================================
--- linux-2.6.12-rc4-mm2.orig/arch/x86_64/kernel/smp.c
+++ linux-2.6.12-rc4-mm2/arch/x86_64/kernel/smp.c
@@ -43,6 +43,13 @@ static cpumask_t flush_cpumask;
static struct mm_struct * flush_mm;
static unsigned long flush_va;
static DEFINE_SPINLOCK(tlbstate_lock);
+
+#ifdef CONFIG_SAFE_IPI_CALLFUNC
+static int safe_ipi_call = 1;
+#else
+static int safe_ipi_call = 0;
+#endif
+
#define FLUSH_ALL -1ULL
/*
@@ -307,6 +314,15 @@ unlock_ipi_calllock(void)
spin_unlock_irq(&call_lock);
}
+static int __init safe_ipi_setup(char *s)
+{
+ safe_ipi_call = 1;
+ printk ("Turning off broadcast IPI in smp_call_function\n");
+ return 0;
+}
+
+__setup("safe_ipi", safe_ipi_setup);
+
/*
* this function sends a 'generic call function' IPI to all other CPUs
* in the system.
@@ -330,7 +346,13 @@ static void __smp_call_function (void (*
call_data = &data;
wmb();
/* Send a message to all other CPUs and wait for them to respond */
- send_IPI_allbutself(CALL_FUNCTION_VECTOR);
+
+ if (safe_ipi_call) {
+ cpumask_t cpu_mask = cpu_online_map;
+ cpu_clear(smp_processor_id(), cpu_mask);
+ send_IPI_mask(cpu_mask, CALL_FUNCTION_VECTOR);
+ } else
+ send_IPI_allbutself(CALL_FUNCTION_VECTOR);
/* Wait for response */
while (atomic_read(&data.started) != cpus)
Index: linux-2.6.12-rc4-mm2/arch/x86_64/Kconfig
===================================================================
--- linux-2.6.12-rc4-mm2.orig/arch/x86_64/Kconfig
+++ linux-2.6.12-rc4-mm2/arch/x86_64/Kconfig
@@ -302,6 +302,10 @@ config HOTPLUG_CPU
can be controlled through /sys/devices/system/cpu/cpu#.
Say N if you want to disable CPU hotplug.
+config SAFE_IPI_CALLFUNC
+ bool
+ default y
+ depends on HOTPLUG_CPU
config HPET_TIMER
bool
--
next prev parent reply other threads:[~2005-05-24 8:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-24 7:27 [patch 0/4] CPU Hotplug support for X86_64 Ashok Raj
2005-05-24 7:27 ` [patch 1/4] " Ashok Raj
2005-05-24 7:27 ` [patch 2/4] " Ashok Raj
2005-05-24 7:27 ` [patch 3/4] " Ashok Raj
2005-05-24 7:27 ` Ashok Raj [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-05-24 8:11 [patch 0/4] " Ashok Raj
2005-05-24 8:11 ` [patch 4/4] " Ashok Raj
2005-05-24 12:28 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050524080801.185401000@csdlinux-2.jf.intel.com \
--to=ashok.raj@intel.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=discuss@x86-64.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustycorp.com.au \
--cc=shaohua.li@intel.com \
--cc=vatsa@in.ibm.com \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox