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

From: Ingo Molnar
Date: Thu Jul 28 2005 - 02:35:18 EST

* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> > a fair number of apps assume that there's _at least_ 100 levels of
> > priorities. The moment you have a custom kernel that offers more than
> > 100 priorities, there will be apps that assume that there are more than
> > 100 priority levels, and will break if there are less.
> That's not the same. The apps on my computer right now should not
> assume that I have 100 priorities. Since I'm free to work with any
> kernel that I want. The customers that ask for a custom kernel are
> also writing custom apps for a specific product. Things can be
> assumed more since the apps are not generic tools that are running on
> desktops. In fact, some of these apps require special hardware to
> work (at least a driver to imitate the hardware).

what i mean is that once there's such a .config option in the generic
kernel, the cat is out of the bag and there's no way back. In other
words, increasing the number of priorities is an irreversible change, in
terms of binary compatibility.

there's absolutely no problem with tweaking your kernel for special
purposes, and i support all the patches to make it easier (as long as
there's no cost to the kernel - and there's no such cost so far). But
whenever some change in the generic kernel has a user-visible effect,
especially one that is pretty much irreversible, we have to be very

(I think in the longer term we might want to do something more clever
than a blanket increase of the priority levels, we could e.g. put a
mapping layer between user priorities and kernel priorities, and in fact
we could make 'user-visible' RT priorities a bit more structured, like a
hierarchy of levels - while keeping the in-kernel priorities a fast &
flat thing (which could have more than 100 levels - but that would not
be visible externally). There's some demand for that, but we'll have to
wait and see for real demand and real code to crystalise out.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at