Extensible scheduler class rejected
Extensible scheduler class rejected
Posted Jul 28, 2023 15:54 UTC (Fri) by mb (subscriber, #50428)In reply to: Extensible scheduler class rejected by kleptog
Parent article: Extensible scheduler class rejected
You just identified the real problem.
Why can't they patch the scheduler?
Posted Jul 28, 2023 21:56 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (2 responses)
I said 'fix', not 'patch'. Anyone can patch the scheduler, the question is if it still works afterwards.
Since the goal of the scheduler is to be the 'one scheduler to rule them all', the term 'fix' means to makes it better for all workloads, even those you've never seen. Most people with an unusual workloads aren't qualified for that, and probably don't care either. They just want it to work for their workload. If a BPF controlled scheduler allows them to solve their problem without having to learn any kernel coding, that's a win.
Ofcourse, my thought is: is anyone qualified to 'fix' the scheduler on these terms? Possibly not. It would have to evolve by slow evolution, and for that you need data. Which can get best gotten by running experiments. You can do that best if you have a mechanism that allows people to quickly and easily try out different things. Like, say, by being able to load little programs into the scheduler to change the behaviour on the fly.
Posted Jul 28, 2023 22:39 UTC (Fri)
by mb (subscriber, #50428)
[Link] (1 responses)
So developing a BPF scheduler is automatically better for all workloads?
> If a BPF controlled scheduler allows them to solve their problem without having
No. It's a hack.
> Like, say, by being able to load little programs into the scheduler to change the behaviour on the fly.
or by patching the freely available C source.
Anybody who can't code C, shall not attempt to develop a new core component of the kernel.
Posted Jul 29, 2023 14:10 UTC (Sat)
by kleptog (subscriber, #1183)
[Link]
> So developing a BPF scheduler is automatically better for all workloads?
Why would it be? It doesn't need to be, because it's not claiming to be the one scheduler to rule them all. I see it as tool that allows people to solve their problems and experiment with alternatives without having to rebuild their kernel each time. It's not trying to replace the existing scheduler. It rather makes it simpler, because then the main scheduler only has to be best for *almost* all workloads, rather than all.
Peter obviously disagrees with this assessment, that's his prerogative. If enterprise software was going to depend on certain scheduler configurations they would have done that already. "Thou shalt only run with the kernel we give you" is not exactly unheard of. Instead we now have the kernel developers requiring people to use out of tree patches, which hardly seems better.
Extensible scheduler class rejected
> Why can't they patch the scheduler?
Extensible scheduler class rejected
> to learn any kernel coding, that's a win.
Extensible scheduler class rejected