From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: Arjan van de Ven <arjanv@infradead.org>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org
Subject: [patch] Voluntary Kernel Preemption, 2.6.12-rc4-mm2
Date: Tue, 24 May 2005 15:21:05 +0200 [thread overview]
Message-ID: <20050524132105.GA29477@elte.hu> (raw)
In-Reply-To: <20050524121541.GA17049@elte.hu>
this patch (ontop of the current -mm scheduler patchset plus the
previous 2 patches from me) adds a new preemption model: 'Voluntary
Kernel Preemption'. The 3 models can be selected from a new menu:
(X) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
( ) Preemptible Kernel (Low-Latency Desktop)
we still default to the stock (Server) preemption model.
Voluntary preemption works by adding a cond_resched()
(reschedule-if-needed) call to every might_sleep() check. It is lighter
than CONFIG_PREEMPT - at the cost of not having as tight latencies. It
represents a different latency/complexity/overhead tradeoff.
it has no runtime impact at all if disabled. Here are size stats that
show how the various preemption models impact the kernel's size:
text data bss dec hex filename
3618774 547184 179896 4345854 424ffe vmlinux.stock
3626406 547184 179896 4353486 426dce vmlinux.voluntary +0.2%
3748414 548640 179896 4476950 445016 vmlinux.preempt +3.5%
voluntary-preempt is +0.2% of .text, preempt is +3.5%.
this feature has been tested for many months by lots of people (and it's
also included in the RHEL4 distribution and earlier variants were in
Fedora as well), and it's intended for users and distributions who dont
want to use full-blown CONFIG_PREEMPT for one reason or another.
the patched kernel builds/boots on my testsystems (x86 and x64) but it
obviously needs more testing. It's simple and straightforward enough to
be considered for upstream inclusion as well, after it gets exposure in
-mm.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
include/linux/kernel.h | 18 +++++++++++----
kernel/Kconfig.preempt | 57 ++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 62 insertions(+), 13 deletions(-)
--- linux/kernel/Kconfig.preempt.orig
+++ linux/kernel/Kconfig.preempt
@@ -1,15 +1,56 @@
-config PREEMPT
- bool "Preemptible Kernel"
+choice
+ prompt "Preemption Model"
+ default PREEMPT_NONE
+
+config PREEMPT_NONE
+ bool "No Forced Preemption (Server)"
+ help
+ This is the traditional Linux preemption model, geared towards
+ throughput. It will still provide good latencies most of the
+ time, but there are no guarantees and occasional longer delays
+ are possible.
+
+ Select this option if you are building a kernel for a server or
+ scientific/computation system, or if you want to maximize the
+ raw processing power of the kernel, irrespective of scheduling
+ latencies.
+
+config PREEMPT_VOLUNTARY
+ bool "Voluntary Kernel Preemption (Desktop)"
help
- This option reduces the latency of the kernel when reacting to
- real-time or interactive events by allowing a low priority process to
- be preempted even if it is in kernel mode executing a system call.
- This allows applications to run more reliably even when the system is
+ This option reduces the latency of the kernel by adding more
+ "explicit preemption points" to the kernel code. These new
+ preemption points have been selected to reduce the maximum
+ latency of rescheduling, providing faster application reactions,
+ at the cost of slighly lower throughput.
+
+ This allows reaction to interactive events by allowing a
+ low priority process to voluntarily preempt itself even if it
+ is in kernel mode executing a system call. This allows
+ applications to run more 'smoothly' even when the system is
under load.
- Say Y here if you are building a kernel for a desktop, embedded
- or real-time system. Say N if you are unsure.
+ Select this if you are building a kernel for a desktop system.
+
+config PREEMPT
+ bool "Preemptible Kernel (Low-Latency Desktop)"
+ help
+ This option reduces the latency of the kernel by making
+ all kernel code (that is not executing in a critical section)
+ preemptible. This allows reaction to interactive events by
+ permitting a low priority process to be preempted involuntarily
+ even if it is in kernel mode executing a system call and would
+ otherwise not be about to reach a natural preemption point.
+ This allows applications to run more 'smoothly' even when the
+ system is under load, at the cost of slighly lower throughput
+ and a slight runtime overhead to kernel code.
+
+ Select this if you are building a kernel for a desktop or
+ embedded system with latency requirements in the milliseconds
+ range.
+
+endchoice
config PREEMPT_BKL
bool "Preempt The Big Kernel Lock"
--- linux/include/linux/kernel.h.orig
+++ linux/include/linux/kernel.h
@@ -58,15 +58,23 @@ struct completion;
* be biten later when the calling function happens to sleep when it is not
* supposed to.
*/
+#ifdef CONFIG_PREEMPT_VOLUNTARY
+extern int cond_resched(void);
+# define might_resched() cond_resched()
+#else
+# define might_resched() do { } while (0)
+#endif
+
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
-#define might_sleep() __might_sleep(__FILE__, __LINE__)
-#define might_sleep_if(cond) do { if (unlikely(cond)) might_sleep(); } while (0)
-void __might_sleep(char *file, int line);
+ void __might_sleep(char *file, int line);
+# define might_sleep() \
+ do { __might_sleep(__FILE__, __LINE__); might_resched(); } while (0)
#else
-#define might_sleep() do {} while(0)
-#define might_sleep_if(cond) do {} while (0)
+# define might_sleep() do { might_resched(); } while (0)
#endif
+#define might_sleep_if(cond) do { if (unlikely(cond)) might_sleep(); } while (0)
+
#define abs(x) ({ \
int __x = (x); \
(__x < 0) ? -__x : __x; \
next prev parent reply other threads:[~2005-05-24 13:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-24 12:15 [patch] remove set_tsk_need_resched() from init_idle() Ingo Molnar
2005-05-24 13:21 ` Ingo Molnar [this message]
2005-05-24 14:56 ` [patch] Voluntary Kernel Preemption, 2.6.12-rc4-mm2 Christoph Hellwig
2005-05-24 15:09 ` Ingo Molnar
2005-05-24 15:21 ` Nick Piggin
2005-05-24 15:33 ` Arjan van de Ven
2005-05-24 15:34 ` Nick Piggin
2005-05-24 15:39 ` Ingo Molnar
2005-05-24 15:59 ` Nick Piggin
2005-05-24 16:11 ` Ingo Molnar
2005-05-25 19:48 ` Christoph Hellwig
2005-05-24 14:06 ` [patch] remove set_tsk_need_resched() from init_idle() Ingo Molnar
2005-05-24 15:02 ` Nick Piggin
2005-05-24 15:05 ` Ingo Molnar
2005-05-24 15:24 ` Nick Piggin
2005-05-24 15:27 ` Ingo Molnar
2005-05-24 15:42 ` Ingo Molnar
2005-05-24 16:00 ` Nick Piggin
2005-05-25 12:24 ` Andrew Morton
2005-05-25 13:51 ` Ingo Molnar
2005-05-25 13:58 ` Ingo Molnar
2005-05-28 16:32 ` Russell King
2005-05-28 18:51 ` Ingo Molnar
2005-05-29 4:05 ` Nick Piggin
2005-05-29 6:01 ` Ingo Molnar
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=20050524132105.GA29477@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=arjanv@infradead.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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