3:23 a.m.
On 21/07/2020 12:13, Qais Yousef wrote:
On 07/21/20 10:36, peterz(a)infradead.org wrote:
> On Mon, Jul 20, 2020 at 06:19:43PM -0400, Steven Rostedt wrote:
>> On Mon, 20 Jul 2020 23:49:18 +0200
>> Peter Zijlstra <peterz(a)infradead.org> wrote:
>>
>>> Steve, would this work for you, or would you prefer renaming the
>>> parameters as well?
>>>
>>
>> Yeah, that's fine. You don't have any sched_fifo_high() ?
>
> Thanks! and no.
>
> I'll go write a Changelog and add it to tip/sched/fifo, so that
> hopefully, sfr can stop complaining about this build fail ;-)
>
> I've even argued we should rename fifo_low() to something else, but
> failed to come up with a sensible name. The intended case is for when
> you want something above normal but don't particularly care about RT at
> all.
>
> The thing is, once you start adding priorities, even low,med,high, we're
> back to where we were. And the whole argument is that the kernel cannot
> set priorities in any sensible fashion.
Agreed. I am worried about in-kernel users setting random uclamp values too.
Do we really have to restrict in-kernel user?
And avoiding module uclamp abuse is covered by 616d91b68cd5 ("sched:
Remove sched_setscheduler*() EXPORTs").
This series should do most of the work but there are more pieces
needed on-top.
From what I see we still need to move the sched_setscheduler() from
include/linux/sched.h to kernel/sched/sched.h. And sched_setattr() too. The
latter has a single user in kernel/trace/trace_selftest.c to create a deadline
task. I think that can be easily wrapped with a similar sched_set_dl()
function and exported instead.
But DL does not have the same issue like the FIFO/RR when it comes to
resource management.
Not sure if we have to restrict in-kernel user.
[...]