On Fri, 2024-01-26 at 15:59 -0600, David Vernet wrote: > 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. The current scheduler must already be using the frequency scaling knobs. Can sched_ext use those knobs directly with hint from userspace easily? > > - 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? This seems like a really nice idea. If we build a kind of library where different components of a schedule are already available, the researchers can just focus on one component and improve it. This could bring long term benefits to schedulers based on sched_ext. This flexibility wasn't possible before for the scheduler. > > 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
