Experimental Patches Allow eBPF To Extend The Linux Kernel's Scheduler

[oiaohm]

I'm a systemd user and I don't mind those uses of eBPF. I'm worried about systemd shipping changes to the scheduler by default, which seems totally like something the devs would do. These sorts of kernel-level modifications have their place in datacentres and specialized devices, but not to be shipped by default on user systems. Scheduling isn't the same as sandboxing; it affects every process running on the system.

I would not say user systems are out.

https://gitlab.com/alfredchen/projectc

There are still third party non mainline schedulers for Linux that attempt to help out with gaming and other desktop workload performance. eBPF scheduler items could allow some of these alterations to be done in a kernel neutral way in future and a lot safer.

Systemd providing a system to allow these ebpf scheduler modifications to be added to system in uniform way would make sense.

saladin you said affects every process in the system altering scheduler really does pay to read the documentation for the patch feature.

https://github.com/htejun/sched_ext/blob/sched_ext/Documentation/scheduler/sched-ext.rst

The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on sysrq-S.

Notice this key feature of sched-ext is that the eBPF schedulers can be terminated and return to tested and proven include Linux kernel scheduler.

Think about this you use alternative scheduler like projectc above it screws up you don't have a ball out 3 finger salute key combination to remove it and return to a more well tested scheduler like you have with sched-ext using eBPF to extend scheduler. Yes the eBPF throws any form of error that is catchable again kernel not panic and die instead returns to default well tested scheduler.

sched-ext is still a work in progress there are still a few places where allowed BPF operations in sched-ext do thing that will truly crash the kernel this is why I said catch-able errors. But this is still a smaller area to screw up than with a full non mainline scheduler and in time should get even smaller. These are in the Caveats section of the documentation.

[oiaohm]

Out of curiosity, how many more (CPU) schedulers we have?

https://helix979.github.io/jkoo/post/os-scheduler/

In mainline technically 2 with multi modes for processes.
RT scheduler designed for real-time task.
CFS scheduler for everything else.
There does appear to be more due to different modes each of those can operate in.

There are a few out of tree ones in this department.

Then you have I/O schedulers. Mainline currently has 3+none it use to be 6+ none. Single que I/O schedulers was removed as of Linux kernel 5.0 this is why the reduction.

https://gitlab.com/alfredchen/projectc

Project C BMQ(Bit Map Queue) and PDS-mq(Priority and Deadline based Skiplist multiple queue) cpu scheduler yes that a process scheduler being the PDS-mq and a I/O scheduler BMQ neither mainline.

Do be aware get these schedulers wrong cause major system problems and these major system problems would be crashes would be best outcome and total data destruction/corruption would be worst outcome. This is why I find this ebpf for schedulers could be better hopefully harder to screw up and cause the bad outcomes.

[marlock]

Delegating vendor-specific scheduler behaviours to eBPF and having a fallback kernel scheduler is a great solution!

If what this means is that vendors can distribute their hardware-specific schedulers (maybe even multiple schedulers which the user can choose between while running - eg: performance, energy-efficiency, energy conservation), users (and Feral's Gaming Mode) can bring their own experiments into the mix, and everyone will leave the kernel freaking alone instead of breaking it... then that's just awesome.


PS: userspace here will probably still require "sudo" unless Gaming Mode or some other agent is provided, so there's also no real security level sacrifice here, right?

[Old Grouch]

systemd hatred is so 2015.

Film at 23:00

[lowflyer]

Why do I always get suspicious when I read something like "Engineers from both Google and Meta (Facebook) are behind this initiative"

[unixfan2001]

Delegating vendor-specific scheduler behaviours to eBPF and having a fallback kernel scheduler is a great solution!

If what this means is that vendors can distribute their hardware-specific schedulers (maybe even multiple schedulers which the user can choose between while running - eg: performance, energy-efficiency, energy conservation), users (and Feral's Gaming Mode) can bring their own experiments into the mix, and everyone will leave the kernel freaking alone instead of breaking it... then that's just awesome.


PS: userspace here will probably still require "sudo" unless Gaming Mode or some other agent is provided, so there's also no real security level sacrifice here, right?

Security will probably be provided through another kernel mechanism, I assume.
Sadly, there are no plans to port seccomp to eBPF, as far as I understand.

[coder]

How would systemd devs ship any kernel scheduler changes?

1. That's not their domain

LOL. Systemd considers everything outside of the kernel to be their domain.

[coder]

Yes the eBPF throws any form of error that is catchable again kernel not panic and die instead returns to default well tested scheduler.

There are more ways to shoot yourself in the foot with a task scheduler than it explicitly throwing errors.

[oiaohm]

There are more ways to shoot yourself in the foot with a task scheduler than it explicitly throwing errors.

True "runnable task stalls, or on sysrq-S." The runnable tasks being stalled is something that raised error out side the ebpf program so there is a watchdog here monitoring scheduler behavour. Of course the developer of this is adding in a key to bail out on all ebpf schedulers and return to stock standard Linux kernel schedulers.

I will agree that this eBPF schedulers are not going to be 100 percent bullet proof. But compare to someone writing their own scheduler from scratch and building their own kernel its going to be safer.

[oiaohm]

Sadly, there are no plans to port seccomp to eBPF, as far as I understand.

https://www.kernel.org/doc/html/late...mp_filter.html

There is seccomp bpf already in the mainline kernel and has been there for a while now.

https://docs.kernel.org/bpf/prog_lsm.html

Yes there is already bpf for making your own mandatory access control system.

Linux kernel is evolving quote a few managed OS features.