The extensible scheduler class

Posted Feb 11, 2023 16:33 UTC (Sat) by dullfire (guest, #111432)
Parent article: The extensible scheduler class

> 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.

to post comments

The extensible scheduler class

Posted Feb 11, 2023 18:34 UTC (Sat) by posk (subscriber, #120275) [Link] (1 responses)

> 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

Posted Feb 12, 2023 0:20 UTC (Sun) by foom (subscriber, #14868) [Link]

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

Posted Feb 12, 2023 20:32 UTC (Sun) by idont (guest, #128754) [Link]

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