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

[Lev Makhlis]

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);