Messages in this thread | | | Date | Wed, 22 Apr 2020 15:26:48 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 01/23] sched: Provide sched_set_fifo() |
| |
On Wed, Apr 22, 2020 at 06:11:38AM -0700, Paul E. McKenney wrote: > On Wed, Apr 22, 2020 at 01:27:20PM +0200, Peter Zijlstra wrote: > > SCHED_FIFO (or any static priority scheduler) is a broken scheduler > > model; it is fundamentally incapable of resource management, the one > > thing an OS is actually supposed to do. > > > > It is impossible to compose static priority workloads. One cannot take > > two well designed and functional static priority workloads and mash > > them together and still expect them to work. > > > > Therefore it doesn't make sense to expose the priority field; the > > kernel is fundamentally incapable of setting a sensible value, it > > needs systems knowledge that it doesn't have. > > > > Take away sched_setschedule() / sched_setattr() from modules and > > replace them with: > > > > - sched_set_fifo(p); create a FIFO task (at prio 50) > > - sched_set_fifo_low(p); create a task higher than NORMAL, > > which ends up being a FIFO task at prio 1. > > - sched_set_normal(p, nice); (re)set the task to normal > > > > This stops the proliferation of randomly chosen, and irrelevant, FIFO > > priorities that dont't really mean anything anyway. > > > > The system administrator/integrator, whoever has insight into the > > actual system design and requirements (userspace) can set-up > > appropriate priorities if and when needed. > > The sched_setscheduler_nocheck() calls in rcu_spawn_gp_kthread(), > rcu_cpu_kthread_setup(), and rcu_spawn_one_boost_kthread() all stay as > is because they all use the rcutree.kthread_prio boot parameter, which is > set at boot time by the system administrator (or {who,what}ever, correct?
Correct, also they are not modular afaict, so they escaped the dance ;-)
| |