Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable

["K.R. Foley" <kr@cybsft.com>]

Esben Nielsen wrote:
> On Wed, 27 Jul 2005, Ingo Molnar wrote:
>
>
> > * Steven Rostedt <rostedt@goodmis.org> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/