Re: [LSF/MM/BPF TOPIC] Discuss more features + use cases for sched_ext

[Muhammad Usama Anjum <musamaanjum@gmail.com>]

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