Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
From: K.R. Foley
Date: Wed Jul 27 2005 - 11:18:11 EST
Esben Nielsen wrote:
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those where custom kernels, and a config
option wasn't necessary. But since I've had customers asking, I
thought that this might be something that others want. But I deal
with a niche market, and what my customers want might not be what
everyone wants. (hence the RFC in the subject).
So if there are others out there that would prefer to change their
priority ranges, speak now otherwise this patch will go by the waste
side.
i'm not excluding that this will become necessary in the future. We
should also add the safety check to sched.h - all i'm suggesting is to
not make it a .config option just now, because that tends to be fiddled
with.
Isn't there a way to mark it "warning! warning! dangerous!" ?
Anyway: I think 100 RT priorities is way overkill - and slowing things
down by making the scheduler checking more empty slots in the runqueue.
Default ought to be 10. In practise it will be very hard to have
a task at the lower RT priority behaving real-time with 99 higher
priority tasks around. I find it hard to believe that somebody has an RT
app needing more than 10 priorities and can't do with RR or FIFO
scheduling within a fewer number of prorities.
Esben
Actually, is it really that slow to search a bitmap for a slot that
needs processing? I work on real-time test stands which are less of an
embedded system and more of a real Unix system that require determinism.
It is very nice in some cases to have more than 10 RT priorities to work
with.
--
kr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/