Messages in this thread | | | From | (David Wagner) | Subject | Re: Linux Kernel Patch; setpriority | Date | 27 Mar 2002 21:19:37 GMT |
| |
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? - 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/
| |