Tejun's address bounced so I am adding the correct one. Thanks. On 1/29/2024 5:41 PM, Joel Fernandes wrote: > > > 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
