On 1/26/2024 4:59 PM, 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. This is a great topic. I think integrating/merging such mechanism with the NEST scheduler could be useful too? You mentioned there is sched_ext implementation of NEST already? One reason that's interesting to me is the task-packing and less-spreading may have power benefits, this is exactly what EAS on ARM does, but it also uses an energy model to know when packing is a bad idea. Since we don't have fine grained control of frequency on Intel, I wonder what else can we do to know when the scheduler should pack and when to spread. Maybe something simple which does not need an energy model but packs based on some other signal/heuristic would be great in the short term. Maybe a signal can be the "Quality of service (QoS)" approach where tasks with lower QoS are packed more aggressively and higher QoS are spread more (?). > > - 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 Maybe I am confused but why does rust userspace code need to link to BPF objects? The BPF object is loaded into the kernel right? > 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 But I get the gist of the issue, would be interesting to discuss. thanks, - Joel
