On Wed, 13 Nov 2024 06:04:59 +0000 Michael Pratt <mcpratt@xxxxx> 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
