On 07/21/20 10:36, pet...@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 <pet...@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. 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. Happy to do the work if you nudge me after you've published this fix on tip or your queue. Thanks -- Qais Yousef
