summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorIngo Molnar <mingo@elte.hu>2005-06-25 23:57:38 +0200
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-06-26 01:24:45 +0200
commitf704f56af95bec3c1ca719d64d0becef74d40899 (patch)
treef024287878246703cf28f738d2c553c476c53c34
parent[PATCH] consolidate PREEMPT options into kernel/Kconfig.preempt (diff)
downloadlinux-f704f56af95bec3c1ca719d64d0becef74d40899.tar.xz
linux-f704f56af95bec3c1ca719d64d0becef74d40899.zip
[PATCH] enable PREEMPT_BKL on !PREEMPT+SMP too
The only sane way to clean up the current 3 lock_kernel() variants seems to be to remove the spinlock-based BKL implementations altogether, and to keep the semaphore-based one only. If we dont want to do that for whatever reason then i'm afraid we have to live with the current complexity. (but i'm open for other cleanup suggestions as well.) To explore this possibility we'll (at a minimum) have to know whether the semaphore-based BKL works fine on plain SMP too. The patch below enables this. The patch may make sense in isolation as well, as it might bring performance benefits: code that would formerly spin on the BKL spinlock will now schedule away and give up the CPU. It might introduce performance regressions as well, if any performance-critical code uses the BKL heavily and gets overscheduled due to the semaphore. I very much hope there is no such performance-critical codepath left though. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-rw-r--r--kernel/Kconfig.preempt2
1 files changed, 1 insertions, 1 deletions
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index 587328be8216..34c631221aa3 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -13,7 +13,7 @@ config PREEMPT
config PREEMPT_BKL
bool "Preempt The Big Kernel Lock"
- depends on PREEMPT
+ depends on SMP || PREEMPT
default y
help
This option reduces the latency of the kernel by making the