On Tue, Sep 2, 2025 at 9:23 AM yikai.lin <yikai.lin@xxxxxxxx> wrote: > > > > On 9/2/2025 1:51 AM, Song Liu wrote: > > On Sun, Aug 31, 2025 at 11:59 PM yikai.lin <yikai.lin@xxxxxxxx> wrote: > > [...] > >> Thanks very much for your comments. > >> The cpuidle governor framework is as follows, > >> and I will include it in the next V2 version. > >> ---------------------------------------------------------- > >> Scheduler Core > >> ---------------------------------------------------------- > >> | > >> v > >> ---------------------------------------------------------- > >> | FAIR Class | EXT Class | IDLE Class | > >> ---------------------------------------------------------- > >> | | | | > >> | | | v > >> | | | ------------------------ > >> | | | enter_cpu_idle() > >> | | | ------------------------ > >> | | | | > >> | | | v > >> | | | ------------------------------ > >> | | | | CPUIDLE Governor | > >> | | | ------------------------------ > >> | | | | | | > >> | | | v v v > >> | | |----------------------------------- > >> | | | default | | other | | BPF ext | > >> | | | Governor | | Governor | | Governor | > >> | | |----------------------------------- > >> | | | | | | > >> | | | v v v > >> | | |------------------------------------- > >> | | | select idle state > >> | | |-------------------------------------> 1. It is not clear to me why a BPF based solution is needed here. Can > >>> we achieve similar benefits with a knob and some userspace daemon? > >>> > >> Each time the system switches to the idle class, it requires a governor policy to select the correct idle state. > >> Currently, we can only switch governor policies through sysfs nodes, as shown below: > >> / # ls /sys/devices/system/cpu/cpuidle/ > >> available_governors current_driver current_governor current_governor_ro > >> / # cat /sys/devices/system/cpu/cpuidle/available_governors > >> menu teo qcom-cpu-lpm 《===Here we can switch governor policy by echo this node. > >> However, it is not possible to change the implementation of this policy through user interfaces. > > > > It is still not clear to me why we need this feature in BPF. From the > > overview, we need two different governors for two different scenarios, > > which can be achieved with a much simpler interface. > > > Thanks for your comments. > > Below is a comparison of traditional governor methods > with a BPF-based approach for dynamic optimization of the cpuidle governor: > > 1.Agile Iteration > -Traditional: > Governor policies require being predetermined and statically embedded before kernel compilation. > -BPF: > Allows dynamic policy iteration based on real-time market user feedback > User-space components can be updated via cloud deployment, > eliminating the need for kernel modifications, recompilation, or reboots. > It is very convenient for mobile device updates. But surely you can add control knobs to a cpuidle governor? > 2.Dynamic Fine-Tuning > -Traditional: > Involves replacing the entire governor, which is less granular. Same here. > -BPF: > Allows granular tuning of governor parameters. > -Examples: > --Screen-off music playback: dynamically enable the "expect_deeper" flag for deeper idle states. > --Gaming scenarios: Allows idle strategy parameters adjustments via user-space signals > (e.g., FPS, charging state) – metrics often opaque to the kernel. > > So, by exposing tunable parameters through BPF maps, > user-space applications could make more run-time parameters adjustments, enhancing precision for specific scenarios. You may as well expose tunable parameters of a cpuidle governors by other means. > Conclusion > ---------- > This approach aims to preserve the common logic of existing Linux governors > while adding flexibility for scenario-specific optimizations on certain SoC platforms or by ODMs. > > Welcome any additional insights you might have on this. I'm still not sure why BPF is needed for any of the things you want to be able to do. Thanks!
