2.4-ac: separate max RT from max user RT

2.4-ac: separate max RT from max user RT

Post by Robert Lov » Thu, 09 May 2002 03:00:14


The attached patch separates the notion of "maximum real-time priority"
from what we actually export to user-space.  This will also us, in the
future, to have kernel threads with a greater RT priority than any user

Right now the two values are set equal and thus the patch has no object
code changes.  It does provide a bit of a cleanup, however.

Patch is against 2.4.19-pre7-ac4, please apply.

        Robert Love

2K Download

2.4-ac: separate max RT from max user RT

Post by Robert Lov » Thu, 09 May 2002 03:40:08

> Patch is against 2.4.19-pre7-ac4, please apply.

Alan et al,

I should also mention the patches are available from


as 145, 165, and 175.  The README explains the chunks.

        Robert Love

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


1. 2.4-ac: user-configurable maximum RT priorities

Attached patch, against 2.4.19-pre8-ac4, creates a compile-time choice
for setting the maximum user and kernel (now separate) real-time
priority.  The patch also does the work of making sure these values are
honored - i.e., cleaning up magic numbers - but most of that was done in
my original MAX_PRIO cleanup.

The maximum user-space exported RT priority is MAX_USER_RT_PRIO and is
set via CONFIG_MAX_USER_RT_PRIO.  It defaults to 100 and has a maximum
of (arbitrarily) 1000.  Anything outside these ranges will be silently
rounded accordingly.  The default RT prios are 0..99 - thus this will
allow priorities to go to 0..999 if desired.

The maximum kernel RT priority is MAX_RT_PRIO and is set via
CONFIG_MAX_RT_PRIO.  It is the absolute maximum priority and is not
exported to user-space.  The configure setting is actually an offset
from MAX_USER_RT_PRIO and thus defaults to zero (i.e. they are the
same).  The maximum allowed is 200.  This would be useful for giving
kernel threads higher priorities than any existing user task.  This
change is possible by the MAX_RT_PRIO cleanup Ingo and I did.

Setting these higher will not break anything but obviously applications
will need to explicit ask for the new priorities.  Since the user is not
allowed to set them lower, there is no risk of breakage.  Since
increasing the priority space increases the size of the priority bitmap,
there is an increase in scheduling overhead.  I have not measured it but
I assume it is negligible.  People who are interested in more real-time
priorities typically have lots of RT tasks, and thus the size of the
bitmask is less relevant since the first bit will always be set early.

Applying this patch and accepting the defaults results in the same
object code as previous.  Those desiring higher values can make the
changes accordingly.  Enjoy.

        Robert Love

6K Download

2. resolution

3. inefficient RT vs efficient non-RT

4. bash script question

5. MAX i-nodes, MAX open files tuning?

6. Problems with ftape-2.08 and Linux 2.0

7. $299.95 /mo Max/Max 10 GB $119 /GB Charged

8. UDP Packet are lost

9. Limiting max load and max netuse

10. iPlanet Error: JVM exit statistics: AttachedThreads/Max=0/0, ActiveThreads/Max=0/0

11. Limit of MAX VGs and MAX FileSystems per machine

12. Max Socket & Max Processes

13. sched define cleanup, separate max priorities