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

[Lev Makhlis]

On Monday 19 November 2001 06:31 am, Albert D. Cahalan wrote:

> > On Monday 19 November 2001 01:01 am, Albert D. Cahalan wrote:
> >> Do not do this. Just supply the raw value for ps(1) and top(1) to use.
> >> Also supply the scheduling policy type. You can tack this on the end
> >> of /proc/<pid>/stat and tell me when Linus accepts it so that I can
> >> make ps(1) and top(1) support the new info.
> >
> > [snip]
> > I think the Right Thing would be to use a f(x) = c - x transormation,
> > where c could be 100, or 0, or -20, or -100, or something else.
> > -20 or -100 have the advantage of preserving the order relationship
> > between priorities across the scheduling policies.
> >
> > The patch below uses c=-100 -- as an example.
>
> I can tell you what procps will do. The very first thing is
> to undo your transformation. Don't bother having the kernel
> muck with the numbers. The procps code will transform the
> numbers as needed to match UNIX convention and/or the tools
> which users run to set these values.

Hmm, how would you explain that the kernel mucks with the numbers
for SCHED_OTHER, but not for SCHED_FIFO/SCHED_RR?
IIRC, procps does not attempt to undo the f(x) = 20 - (10x + 5) / 10
(assuming HZ=100) transformation currently used for SCHED_OTHER.

Granted, procps can do the transformation itself, but procps does not
have a monopoly on using procfs data -- any other performance-monitoring
application would have to duplicate the transformation, if it is to be
consistent with the standard (procps) tools.  I thought it would be
nice if the kernel provided a consistent interface through procfs to
begin with.