Another push for sched_ext

Posted May 16, 2024 9:14 UTC (Thu) by rwmj (subscriber, #5474)
Parent article: Another push for sched_ext

I have a couple of technical questions which I don't think were answered in the article or comments so far ...

(1) Is BPF actually fast enough here? I mean, surely this code is called every time you do schedule(), which would be very frequent, so you'd want that to be as fast as it can be. BPF is JITted but does it compete with AOT-compiled C code?

(2) Related to (1), why wouldn't a pluggable system of regular kernel modules work for this use case? From a quick scan of kernel/sched in the sources it seems like the current schedulers are not modules.

Another push for sched_ext

Posted May 16, 2024 13:27 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

I'm not the expert in this area, but can try to answer the questions...

As I understand it, BPF is indeed fast enough to use in this way. It's all native code by the time it runs.

Using regular modules would forego many of the safety features of BPF, making it much easier to hose the system. That would be undesirable in a system meant to encourage experimentation.

Another push for sched_ext

Posted May 17, 2024 14:57 UTC (Fri) by daroc (editor, #160859) [Link]

I'll also note that many of the sched_ext folks I've spoken with have been hopeful that people will use sched_ext for experimentation, and then contribute those algorithms as actual schedulers later, avoiding any overhead left from the JIT. I attended a talk at LFSMM (article forthcoming) where the speaker mentioned that BPF now has almost all the features needed to implement EEVDF — the main remaining item being the ability to safely call kfuncs while holding a lock — at which point they hope to see people use sched_ext to experiment directly on EEVDF.