public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
Subject: [patch 4/4] CPU Hotplug support for X86_64
Date: Tue, 24 May 2005 01:11:17 -0700	[thread overview]
Message-ID: <20050524081305.149581000@csdlinux-2.jf.intel.com> (raw)
In-Reply-To: 20050524081113.409604000@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

--

  parent reply	other threads:[~2005-05-24  8:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-24  8:11 [patch 0/4] CPU Hotplug support for X86_64 Ashok Raj
2005-05-24  8:11 ` [patch 1/4] " Ashok Raj
2005-05-24 12:15   ` Andi Kleen
2005-05-24 15:51     ` Ashok Raj
2005-05-24 18:18       ` Andi Kleen
2005-05-24  8:11 ` [patch 2/4] " Ashok Raj
2005-05-24 12:24   ` Andi Kleen
2005-05-24  8:11 ` [patch 3/4] " Ashok Raj
2005-05-24 12:27   ` Andi Kleen
2005-05-24  8:11 ` Ashok Raj [this message]
2005-05-24 12:28   ` [patch 4/4] " Andi Kleen
2005-05-24  9:31 ` [patch 0/4] " Shaohua Li
2005-05-25 22:16   ` Matthew Dobson
2005-05-26  0:11     ` Ashok Raj
  -- strict thread matches above, loose matches on Subject: below --
2005-05-24  7:27 Ashok Raj
2005-05-24  7:27 ` [patch 4/4] " Ashok Raj

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=20050524081305.149581000@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