On Wed, 13 Nov 2024 06:04:59 +0000 Michael Pratt mcpratt@pm.me wrote:
$ man sched_setscheduler [..] SCHED_OTHER the standard round-robin time-sharing policy;
SCHED_BATCH for "batch" style execution of processes; and
SCHED_IDLE for running very low priority background jobs.
For each of the above policies, param->sched_priority must be 0.
Where we already document that the sched_priority "must be 0".
I think we should all agree that documentation is a summary of development, not the other way around. Not only that, but this is poor documentation. The kernel is subject to change, imagine using the word "always" for design decisions that are not standardized. A more appropriate description would be "for each policy, sched_priority must be within the range provided by the return of [the query system calls]" just as POSIX describes the relationship.
As far as I can see, the "must be 0" requirement is completely arbitrary, or, if there is a reason, it must be a fairly poor one. However, I do recognize that the actual static priority cannot change, hence the adjustment to niceness instead is the obvious intention to any attempt to adjust the priority on the kernel-side from userspace.
I consider this patch to be a fix for a design decision that makes no sense when reading about the intended purpose of these values, not that it's the only way to achieve the priority adjustment. If anyone considers that something this simple should have been done already, the fact that documentation would have to be adjusted should not block it. Besides, a well-written program would already have been using the functions that return the accepted range before executing the sched_setscheduler() system call with a value that would be rejected.
Am I really the only one to read that you can't set the priority with this system call when I can do it on the command line with the "nice" program which uses a different system call, and ask "what's the point of this restriction?"
Honestly, I would actually prefer your change. But modifying an existing API is above my pay grade ;-) I think you really need Linus to answer that.
Linus?
-- Steve