The extensible scheduler class

Posted Feb 11, 2023 18:34 UTC (Sat) by posk (subscriber, #120275)
In reply to: The extensible scheduler class by dullfire
Parent article: The extensible scheduler class

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

to post comments

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!")