Hello, A few more use cases have emerged for sched_ext that are not yet supported that I wanted to discuss in the BPF track. Specifically: - EAS: Energy Aware Scheduling While firmware ultimately controls the frequency of a core, the kernel does provide frequency scaling knobs such as EPP. It could be useful for BPF schedulers to have control over these knobs to e.g. hint that certain cores should keep a lower frequency and operate as E cores. This could have applications in battery-aware devices, or in other contexts where applications have e.g. latency-sensitive compute-intensive workloads. - Componentized schedulers Scheduler implementations today largely have to reinvent the wheel. For example, if you want to implement a load balancer in rust, you need to add the necessary fields to the BPF program for tracking load / duty cycle, and then parse and consume them from the rust side. That's pretty suboptimal though, as the actual load balancing algorithm itself is essentially the exact same. The challenge here is that the feature requires both BPF and user space components to work together. It's not enough to ship a rust crate -- you need to also ship a BPF object file that your program can link against. And what should the API look like on both ends? Should rust / BPF have to call into functions to get load balancing? Or should it be automatically packaged and implemented? There are a lot of ways that we can approach this, and it probably warrants discussing in some more detail. If anybody else has ideas on things they'd like to discuss; either sched_ext features that are missing, or scheduling ideas that we could try to implement but just haven't yet, please feel free to share. Thanks, David
Attachment:
signature.asc
Description: PGP signature
