LWN: Comments on "The extensible scheduler class"

The extensible scheduler class

mrugiero — Thu, 23 Feb 2023 12:20:01 +0000

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.

The extensible scheduler class

Ongy — Thu, 23 Feb 2023 08:45:45 +0000

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

jcpunk — Fri, 17 Feb 2023 15:55:23 +0000

This feels like it circles back around to last week's discussion on stable BPF interfaces.

If folks are given a "use bpf to implement your custom scheduler workload" they'll be super unhappy if they have to rewrite bits of it because the kernel internals changed.

The extensible scheduler class

idont — Sun, 12 Feb 2023 20:32:45 +0000

I think AIX supports M:N scheduling, though I can't say anything about its performance:
https://www.ibm.com/docs/en/aix/7.3?topic=multiprocessing...

Looks like it's unsupported starting from 7.3 as well

The extensible scheduler class

gerdesj — Sun, 12 Feb 2023 00:52:37 +0000

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

foom — Sun, 12 Feb 2023 00:20:48 +0000

Hmm, I think I'd call Google fibers 1:1, at least in the way most people would mean it. That is, it assigns every userspace thread to a dedicated kernel thread, from the first time the thread function runs, until that function returns.

The magic seems all about having userspace code choose which threads are runnable at any given time -- ensuring that there's only ever 1 "runnable" thread per CPU the process is allowed to use. The most tricky part of that being the ability to cause a new thread to be made chosen to be runnable if another blocks in the kernel.

By ensuring this, the kernel scheduler's decisions are made effectively trivial. ("N CPUs are available, and N threads are currently runnable? Ok I know what to do here!")

The extensible scheduler class

posk — Sat, 11 Feb 2023 18:34:49 +0000

> Honestly: this line makes me think linux should try to take a stab at the whole M:N scheduling thing again (which AFAIK no implementations, on any OS/kernel, have been successful/performant thus far). With a (small) M:N syscall interface, you could have a scheduling user-space "process". That process should be a realtime scheduled, and then you get the full power of a plug-able scheduler AND the ability to write it in any language you have a runtime/compiler for.

Google Fibers is an M:N in-process scheduling framework that has been used internally at Google for 10+ years, quite successfully. There have been several attempts to upstream the kernel side of it (UMCG, FUTEX_SWAP).

The extensible scheduler class

dullfire — Sat, 11 Feb 2023 16:33:48 +0000

> BPF-written schedulers can also improve performance for niche workloads that may not be worth supporting in the mainline kernel and are much easier to deploy to a large fleet of systems.

Honestly: this line makes me think linux should try to take a stab at the whole M:N scheduling thing again (which AFAIK no implementations, on any OS/kernel, have been successful/performant thus far). With a (small) M:N syscall interface, you could have a scheduling user-space "process". That process should be a realtime scheduled, and then you get the full power of a plug-able scheduler AND the ability to write it in any language you have a runtime/compiler for.

The extensible scheduler class

hyeyoo — Sat, 11 Feb 2023 09:23:57 +0000

I wonder WALT on android common kernel can be implemented using this feature.

The extensible scheduler class

flussence — Fri, 10 Feb 2023 19:53:41 +0000

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.