Extensible scheduler class rejected
Extensible scheduler class rejected
Posted Jul 28, 2023 6:28 UTC (Fri) by mb (subscriber, #50428)In reply to: Extensible scheduler class rejected by quotemstr
Parent article: Extensible scheduler class rejected
The problem with a user programmable scheduler is, that this will hurt the overall ecosystem in the long term by creating thousands of "special" flowers.
Posted Jul 28, 2023 9:51 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (4 responses)
This is a terrible argument.
The problem with a user-programmable computer is, that this will hurt the overall ecosystem in the long term by creating thousands of "special" flowers.
The problem with a user-modifiable kernel is, that this will hurt the overall ecosystem in the long term by creating thousands of "special" flowers.
The problem with a user-configurable desktop is, that this will hurt the overall ecosystem in the long term by creating thousands of "special" flowers.
Unless there are really good reason, the trend is always to *more* configurability, not less. The problem is now that the people with the broken workloads can't fix the scheduler, and the people who can fix the scheduler don't know the workloads. At least with a generally accepted user-modifiable scheduler people could start communicating and collaborating about what works for them and we'd get progress, because the people with the workloads can actually try things out easily. As long as it's out of tree that will never happen, because you have no way to testing whether a change will affect normal users negatively.
Also, the idea that it's possible to build a single scheduler that works well for everyone is (from what I can tell) an assumption without basis.
Posted Jul 28, 2023 15:54 UTC (Fri)
by mb (subscriber, #50428)
[Link] (3 responses)
You just identified the real problem.
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
Extensible scheduler class rejected
Why can't they patch the scheduler?
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