Bug or feature? Priority in /proc/<pid>/stat for RT processes

Lev Makhlis (mlev@despammed.com)
Sat, 13 Oct 2001 14:09:12 -0400


I have noticed that when the scheduling policy of a process is SCHED_FIFO
or SCHED_RR, proc_pid_stat() in fs/proc/array.c still uses the counter field
in the task structure to calculate the priority in /proc/<pid>/stat.
For such processes, the counter field is ignored by the scheduler in favour
of the rt_priority field. Thus, even though the actual priority is available
via sched_getparam(2), the priority in /proc/<pid>/stat -- and, consequently,
in the output of ps(1) and top(1) -- seems to be, for SCHED_FIFO/SCHED_RR
processes, a value that is not representative at all of how the process is
scheduled.

I have thrown together a patch to address this, but I can't say I feel
entirely comfortable about scaling from 1..99 to -20..20.

Any comments would be appreciated.

Lev Makhlis

-------------------------------CUT HERE---------------------------------
--- linux-2.4.12/fs/proc/array.c Sat Oct 13 13:09:29 2001
+++ linux/fs/proc/array.c Sat Oct 13 13:21:05 2001
@@ -334,8 +334,13 @@

/* scale priority and nice values from timeslices to -20..20 */
/* to make it look like a "normal" Unix priority/nice value */
- priority = task->counter;
- priority = 20 - (priority * 10 + DEF_COUNTER / 2) / DEF_COUNTER;
+ if ((task->policy & ~SCHED_YIELD) == SCHED_OTHER) {
+ priority = task->counter;
+ priority = 20 - (priority * 10 + DEF_COUNTER / 2) / DEF_COUNTER;
+ } else {
+ priority = task->rt_priority;
+ priority = 20 - (priority * 40 + 50) / 100;
+ }
nice = task->nice;

read_lock(&tasklist_lock);
-
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/