Skip to contentSkip to conversation

2.4-ac: user-configurable maximum RT priorities

PATCH New Robert Love 1 participant 1 message May 17, 2002

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/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

Documentation/Configure.help +32 -0
diff -urN linux-2.4.19-pre8-ac4/Documentation/Configure.help linux/Documentation/Configure.help
@@ -3945,6 +3945,38 @@
   you have use for it; the module is called binfmt_misc.o. If you
   don't know what to answer at this point, say Y.
 
+Maximum User Real-Time Priority
+CONFIG_MAX_USER_RT_PRIO
+  The maximum user real-time priority. Tasks with priorities from
+  zero through one less than this value are scheduled as real-time.
+  To the application, a higher priority value implies a higher
+  priority task.
+
+  The minimum allowed value is 100 and the maximum allowed value
+  is (arbitrary) 1000. Values specified outside this range will
+  be rounded accordingly during compile-time. The default is 100.
+  Setting this higher than 100 is safe but will result in slightly
+  more processing overhead in the scheduler. 
+
+  Unless you are doing specialized real-time computing and require
+  a much larger range than usual, the default is fine.
+
+Maximum Kernel Real-Time Priority
+CONFIG_MAX_RT_PRIO
+  The difference between the maximum real-time priority and the
+  maximum user real-time priority.  Usually this value is zero,
+  which sets the maximum real-time priority to the same as the
+  maximum user real-time priority.  Setting this higher,
+  however, will allow kernel threads to set their priority to a
+  value higher than any user task. This is safe, but will result
+  in slightly more processing overhead in the scheduler.
+
+  This value can be at most 200.  The default is zero, i.e. the
+  maximum priority and maximum user priority are the same.
+
+  Unless you are doing specialized real-time programming with
+  kernel threads, the default is fine.
+
 Kernel support for JAVA binaries
 CONFIG_BINFMT_JAVA
   If you say Y here, the kernel will load and execute Java J-code
arch/i386/config.in +2 -0
diff -urN linux-2.4.19-pre8-ac4/arch/i386/config.in linux/arch/i386/config.in
@@ -271,6 +271,8 @@
 
 bool 'System V IPC' CONFIG_SYSVIPC
 bool 'BSD Process Accounting' CONFIG_BSD_PROCESS_ACCT
+int 'Maximum User Real-Time Priority' CONFIG_MAX_USER_RT_PRIO 100
+int 'Maximum Kernel Real-time Priority' CONFIG_MAX_RT_PRIO 0
 bool 'Sysctl support' CONFIG_SYSCTL
 if [ "$CONFIG_PROC_FS" = "y" ]; then
    choice 'Kernel core (/proc/kcore) format' \
include/asm-i386/mmu_context.h +1 -1
diff -urN linux-2.4.19-pre8-ac4/include/asm-i386/mmu_context.h linux/include/asm-i386/mmu_context.h
@@ -12,7 +12,7 @@
  * unlikely to be set. It's guaranteed that at least one of the 140
  * bits is cleared.
  */
-static inline int sched_find_first_bit(unsigned long *b)
+static inline int _sched_find_first_bit(unsigned long *b)
 {
 	if (unlikely(b[0]))
 		return __ffs(b[0]);
include/linux/sched.h +47 -2

61 lines not on this page · raw message

kernel/sched.c +0 -14
diff -urN linux-2.4.19-pre8-ac4/kernel/sched.c linux/kernel/sched.c
@@ -22,20 +22,6 @@
 #include <linux/kernel_stat.h>
 
 /*
- * Priority of a process goes from 0 to 139. The 0-99
- * priority range is allocated to RT tasks, the 100-139
- * range is for SCHED_OTHER tasks. Priority values are
- * inverted: lower p->prio value means higher priority.
- * 
- * MAX_USER_RT_PRIO allows the actual maximum RT priority
- * to be separate from the value exported to user-space.
- * NOTE: MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
- */
-#define MAX_RT_PRIO		100
-#define MAX_USER_RT_PRIO	100
-#define MAX_PRIO		(MAX_RT_PRIO + 40)
-
-/*
  * Convert user-nice values [ -20 ... 0 ... 19 ]
  * to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ],
  * and back.