Messages in this thread Patch in this message |  | | From | Lev Makhlis <> | Subject | Bug or feature? Priority in /proc/<pid>/stat for RT processes | Date | 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/
|  |