Re: [PATCH RESEND 2 1/1] sched/syscalls: Allow setting niceness using sched_param struct

[Steven Rostedt]

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