The extensible scheduler class

Posted Feb 10, 2023 19:53 UTC (Fri) by flussence (guest, #85566)
Parent article: The extensible scheduler class

I'm starting to see the real value of this BPF thing. A stable API that doesn't require juggling rapidly bitrotting out-of-tree patchsets for hordes of demanding users, an idiot-proof sandbox for phone manufacturers to put their value-adds in, no more gatekeepers pulling the "rejected, CFS works fine on my $3000 workstation" for 20 years... maybe you *can* solve social problems through technological means.

Or maybe Linux will proudly make no attempt to keep up with the ongoing tidal wave of mainstream x86/ARM core arrangements that don't fit neatly into a C array and we'll end up with a sequel to the Wasted Cores paper. Right now that looks more likely.

to post comments

The extensible scheduler class

Posted Feb 12, 2023 0:52 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (1 responses)

Some parts of your argument come across clearly but it is not a coherent whole.

It's great that you are seeing "the real value" but why not let us know why.

The extensible scheduler class

Posted Feb 23, 2023 8:45 UTC (Thu) by Ongy (subscriber, #161805) [Link]

I feel like the first half is half of what I've been feeling about some developments with Linux.

We are starting to see more and more pluggable and microkernel (userspace) approaches inside the kernel. With drivers, schedulers, LSM I think to some degree even memory allocation (faultfd or whatever the name is).

Which is great. People can experiment, we get better fault safety for drivers, and if upstream is too slow or (arguably) too much of a nuisance, vendors can still ship drivers.

OTOH I really dislike what this enables as well. Vendors get to avoid the GPL. Intel already provides a closed source driver for webcams and touchscreens iirc. by means of having it run in userspace.

It's a really double edged sword. While we might get more drivers faster/easier to backport, it also reduces the pressure on vendors to "play nice" and especially to provide open implementations of how to talk to their hardware.

The extensible scheduler class

Posted Feb 23, 2023 12:20 UTC (Thu) by mrugiero (guest, #153040) [Link]

I'm not really sure what I feel about pluggable schedulers (it sounds like a good idea superficially, but I don't know the domain enough to emit judgement), but I can't really see why Zijlstra sees the BPF as a worsening over other proposals. IMO that's a net improvement if only because we don't need yet another unstable idiosyncratic API that negates any advantage of the approach in the first place. Even if the idea is bad, BPF sounds like the right way to implement it to me.