From: Steven Rostedt <rostedt@goodmis.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Ingo Molnar <mingo@elte.hu>
Subject: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Date: Wed, 27 Jul 2005 10:13:15 -0400 [thread overview]
Message-ID: <1122473595.29823.60.camel@localhost.localdomain> (raw)
The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO
configurable from the make *config. This is more of a proposal since
I'm not really sure where in Kconfig this would best fit. I don't see
why these options shouldn't be user configurable without going into the
kernel headers to change them.
Also, is there a way in the Kconfig to force the checking of
MAX_USER_RT_PRIO <= MAX_RT_PRIO?
-- Steve
(Patched against 2.6.12.2)
Index: vanilla_kernel/include/linux/sched.h
===================================================================
--- vanilla_kernel/include/linux/sched.h (revision 263)
+++ vanilla_kernel/include/linux/sched.h (working copy)
@@ -389,9 +389,13 @@
* MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
*/
-#define MAX_USER_RT_PRIO 100
-#define MAX_RT_PRIO MAX_USER_RT_PRIO
+#define MAX_USER_RT_PRIO CONFIG_MAX_USER_RT_PRIO
+#define MAX_RT_PRIO CONFIG_MAX_RT_PRIO
+#if MAX_USER_RT_PRIO > MAX_RT_PRIO
+#error MAX_USER_RT_PRIO must not be greater than MAX_RT_PRIO
+#endif
+
#define MAX_PRIO (MAX_RT_PRIO + 40)
#define rt_task(p) (unlikely((p)->prio < MAX_RT_PRIO))
Index: vanilla_kernel/init/Kconfig
===================================================================
--- vanilla_kernel/init/Kconfig (revision 263)
+++ vanilla_kernel/init/Kconfig (working copy)
@@ -162,6 +162,32 @@
building a kernel for install/rescue disks or your system is very
limited in memory.
+config MAX_RT_PRIO
+ int "Maximum RT priority"
+ default 100
+ help
+ The real-time priority of threads that have the policy of SCHED_FIFO
+ or SCHED_RR have a priority higher than normal threads. This range
+ can be set here, where the range starts from 0 to MAX_RT_PRIO-1.
+ If this range is higher than MAX_USER_RT_PRIO than kernel threads
+ may have a higher priority than any user thread.
+
+ This may be the same as MAX_USER_RT_PRIO, but do not set this
+ to be less than MAX_USER_RT_PRIO.
+
+config MAX_USER_RT_PRIO
+ int "Maximum User RT priority"
+ default 100
+ help
+ The real-time priority of threads that have the policy of SCHED_FIFO
+ or SCHED_RR have a priority higher than normal threads. This range
+ can be set here, where the range starts from 0 to MAX_USER_RT_PRIO-1.
+ If this range is lower than MAX_RT_PRIO, than kernel threads may have
+ a higher priority than any user thread.
+
+ This may be the same as MAX_RT_PRIO, but do not set this to be
+ greater than MAX_RT_PRIO.
+
config AUDIT
bool "Auditing support"
default y if SECURITY_SELINUX
next reply other threads:[~2005-07-27 14:13 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-27 14:13 Steven Rostedt [this message]
2005-07-27 14:17 ` [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable Ingo Molnar
2005-07-27 14:26 ` Steven Rostedt
2005-07-27 14:33 ` Ingo Molnar
2005-07-27 14:47 ` [PATCH] safty check of MAX_RT_PRIO >= MAX_USER_RT_PRIO Steven Rostedt
2005-07-27 15:05 ` Steven Rostedt
2005-07-27 18:52 ` Ingo Molnar
2005-07-27 14:53 ` [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable Esben Nielsen
2005-07-27 15:02 ` Steven Rostedt
2005-07-27 16:09 ` K.R. Foley
2005-07-27 17:01 ` Esben Nielsen
2005-07-27 17:25 ` Steven Rostedt
2005-07-27 21:32 ` Esben Nielsen
2005-07-28 12:17 ` Steven Rostedt
2005-07-28 7:22 ` Ingo Molnar
2005-07-28 11:53 ` Steven Rostedt
2005-07-27 17:42 ` K.R. Foley
2005-07-28 9:59 ` Esben Nielsen
2005-07-27 14:28 ` Steven Rostedt
2005-07-27 14:38 ` Ingo Molnar
2005-07-27 14:46 ` Steven Rostedt
2005-07-28 7:33 ` Ingo Molnar
2005-07-28 1:42 ` Matt Mackall
2005-07-28 1:00 ` Daniel Walker
2005-07-28 1:20 ` Lee Revell
2005-07-28 1:26 ` Steven Rostedt
2005-07-28 1:25 ` Steven Rostedt
2005-07-28 3:06 ` Steven Rostedt
2005-07-28 3:32 ` Steven Rostedt
2005-07-28 3:45 ` Steven Rostedt
2005-07-28 3:51 ` Nick Piggin
2005-07-28 11:43 ` [PATCH] speed up on find_first_bit for i386 (let compiler do the work) Steven Rostedt
2005-07-28 12:45 ` Steven Rostedt
2005-07-28 15:31 ` Linus Torvalds
2005-07-28 15:30 ` Linus Torvalds
2005-07-28 15:47 ` Steven Rostedt
2005-07-28 16:34 ` Maciej W. Rozycki
2005-07-28 16:57 ` Steven Rostedt
2005-07-28 17:25 ` Linus Torvalds
2005-07-29 10:03 ` David Woodhouse
2005-07-29 14:41 ` Maciej W. Rozycki
2005-07-29 16:23 ` Linus Torvalds
2005-07-29 14:39 ` Maciej W. Rozycki
2005-07-29 16:29 ` Linus Torvalds
2005-07-29 17:14 ` Maciej W. Rozycki
2005-07-28 17:17 ` Linus Torvalds
2005-07-29 15:09 ` Maciej W. Rozycki
2005-07-28 18:25 ` Steven Rostedt
2005-07-28 18:56 ` Linus Torvalds
2005-07-28 17:52 ` Mitchell Blank Jr
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=1122473595.29823.60.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@osdl.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.