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

[phoronix]

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

A set of "request for comments" patches posted today to the Linux kernel mailing list implement support for CPU scheduler policies to be implemented as (e)BPF programs...

https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler

[saladin]

This just sounds like an accident about to happen if systemd hears about this.

[RahulSundaram]

This just sounds like an accident about to happen if systemd hears about this.

systemd already uses ebpf. If kernel exposes an API and userspace uses it, that is no accident.

[mangeek]

I think this could be very exciting. With more CPUs having heterogeneous topology, I suspect more scheduler configuration options are warranted. This will also potentially ease backporting and OEM-provided new schedulers in long-term kernels published with this funtionality.

[unixfan2001]

This just sounds like an accident about to happen if systemd hears about this.

systemd hatred is so 2015.

[saladin]

systemd already uses ebpf. If kernel exposes an API and userspace uses it, that is no accident.

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.

[unixfan2001]

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.

How would systemd devs ship any kernel scheduler changes?

1. That's not their domain
2. There's already more than one scheduler
3. This is about application specific schedulers in userspace

[RahulSundaram]

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.

An assertion about systemd developers without evidence on a topic that doesn't really have anything to do with systemd. Ok, let's go with that. Are distributions also assumed to just blindly ship scheduler changes? How is that different from them shipping an ebpf patch to do it if they want to and not use systemd for it?

[unixfan2001]

An assertion about systemd developers without evidence on a topic that doesn't really have anything to do with systemd. Ok, let's go with that. Are distributions also assumed to just blindly ship scheduler changes? How is that different from them shipping an ebpf patch to do it if they want to and not use systemd for it?

This! This isn't KolibriOS or Snowdrop OS. We're talking about several scarcely related FOSS projects with completely different leadership and leadership structure.

"Hello, my fellow systemd users! I too love systemd but tomorrow evil Adolf Poettering will remove every single coreutil except echo(1). But echo(1), no matter what you type, will slowly print out 'I love systemd! HAIL Poettering!' with every keystroke, indefinitely. There's nothing we can do about it as the Great Hacker Poettering has not only hijacked every single software repository but also kidnapped Linus Torvalds, Greg Kroah Hartman and all the distro owners."

Some people actually think like this.

[amxfonseca]

2. There's already more than one scheduler

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