Re: Linux Kernel Patch; setpriority

[daw@mozart.cs.berkeley.edu (David Wagner)]

What's the argument why this change to the semantics of setpriority()
is a reasonable one to make?

Previously, non-root users [*] could not decrement their current priority
value (i.e., make their own processes run faster).  Now you're allowing
processes to decrement the current priority, so long as they stay within
the range 0..19.  But what if the priority had been increased by the
scheduler because this process was running a long time and taking up
a lot of CPU time?  The proposed change to the setpriority() interface
allows such a process to "cheat" and get more CPU time than it ought to
be able to receive.

It seems to me that the scheduler should be able to renice a CPU hog
to make sure that interactive processes receive good performance, and
your proposed change circumvents this.  It's one thing for a process
to decrement its priority if this process was the one who voluntarily
incremented it earlier; it's another thing if the priority value was
incremented forcibly by the OS.  If this is correct, the proposed change
doesn't look so good.

Am I overlooking something?