From: Max Krasnyansky <[EMAIL PROTECTED]>

This patch is trying to address the same use case I explained in the previous 
workqueue
isolation patch. Which is when a high priority realtime (FIFO, RR) user-space 
thread
is using 100% CPU for extended periods of time. In which case stopmachine 
threads do not
get a chance to run and entire machine essentially hangs because other CPUs are 
waiting
for the all stopmachine threads to run.
This use case is perfectly valid if one is using a CPU as a dedicated engine
(crunching numbers, hard realtime, etc). Think of it as an SPE in the Cell 
processor.
Which is what CPU isolation enables in first place.

Stopmachine is particularly bad when it comes to latencies. It's currently used 
for
module insertion and removal only. Given that threads running on the isolated 
CPUs
are unlikely to use kernel services anyway I'd consider this patch pretty safe.

The patch adds no overhead and/or side effects when CPU isolation is disabled.

Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
 kernel/stop_machine.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 51b5ee5..0f4cc3f 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -99,7 +99,7 @@ static int stop_machine(void)
        stopmachine_state = STOPMACHINE_WAIT;
 
        for_each_online_cpu(i) {
-               if (i == raw_smp_processor_id())
+               if (i == raw_smp_processor_id() || cpu_isolated(i))
                        continue;
                ret = kernel_thread(stopmachine, (void *)(long)i,CLONE_KERNEL);
                if (ret < 0)
-- 
1.5.3.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to