>> 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.
> I agree scaling from 1.99 to 20..-20 wasn't a good idea, but I don't think
> supplying the raw (1..99) value without any transformation at all would be
> right either -- I think we need to reverse its sign, for the following
> If you look at what happens on other Unix platforms, the "direction"
> of priority values can vary: usually, higher values mean lower priority,
> but, for example, on Solaris, higher values mean higher priority.
> But on any specific platform, the "direction" is consistent across
> the different scheduling policies. On Linux, it's "higher value = lower
> priority" for the default timesharing policy, and therefore I think it should
> be the same for the RT priorities.
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/