-
Notifications
You must be signed in to change notification settings - Fork 152
scx_utils: Add EnergyModel (energy_model.rs). #1624
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ba5a79e
to
c016769
Compare
htejun
reviewed
Apr 3, 2025
htejun
approved these changes
Apr 3, 2025
hodgesds
reviewed
Apr 3, 2025
Signed-off-by: Changwoo Min <[email protected]>
94addbf
to
2b121bb
Compare
Schedulers need to know the energy model of a system to make energy-aware scheduling decisions. The EnergyModel (energy_model.rs) represents the energy model of a system. It loads the energy model data from debugfs (typically at /sys/kernel/debug/energy_model), so the kernel should support not only the energy model (CONFIG_ENERGY_MODEL) but also debugfs. A system's energy model (EnergyModel) consists of one or more performance domains (PerfDomain). A group of CPUs belonging to the same performance domain is frequency-scaled altogether (i.e., the same frequency domain), so it has the same performance-power characteristics. The performance-power attributes of a performance domain are represented by a collection of performance states (PerfState). Each performance state includes 1) CPU frequency (kHz), 2) the cost of the transition, 3) performance scaled by 1024 against the highest performance of the fastest CPU, 4) power consumption (mW), and 5) whether this state is power-inefficient or not. Signed-off-by: Changwoo Min <[email protected]>
2b121bb
to
9c9fd2b
Compare
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Apr 15, 2025
The sched_ext schedulers [1] currently access the energy model through the debugfs to make energy-aware scheduling decisions [2]. The userspace part of a sched_ext scheduler feeds the necessary (post-processed) energy-model information to the BPF part of the scheduler. However, there is a limitation in the current debugfs support of the energy model. When the energy model is updated (em_dev_update_perf_domain), there is no way for the userspace part to know such changes (besides polling the debugfs files). Therefore, add inotify support (IN_MODIFY) when the energy model is updated. With this inotify support, the sched_ext scheduler can monitor the energy model change in userspace using the regular inotify interface and feed the updated energy model information to make energy-aware scheduling decisions. [1] https://lwn.net/Articles/922405/ [2] sched-ext/scx#1624 Signed-off-by: Changwoo Min <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
May 7, 2025
The sched_ext schedulers [1] currently access the energy model through the debugfs to make energy-aware scheduling decisions [2]. The userspace part of a sched_ext scheduler feeds the necessary (post-processed) energy-model information to the BPF part of the scheduler. However, there is a limitation in the current debugfs support of the energy model. When the energy model is updated (em_dev_update_perf_domain), there is no way for the userspace part to know such changes (besides polling the debugfs files). Therefore, add inotify support (IN_MODIFY) when the energy model is updated. With this inotify support, the directory of an updated performance domain (e.g., /sys/kernel/debug/energy_model/cpu0) and its parent directory (e.g., /sys/kernel/debug/energy_model) are inotified. Therefore, a sched_ext scheduler (or any userspace application) monitors the energy model change in userspace using the regular inotify interface. Note that accessing the energy model information from userspace has many advantages over other alternatives, especially adding new BPF kfuncs. The userspace has much more freedom than the BPF code (e.g., using external libraries and floating point arithmetics), which may be infeasible (if not impossible) in the BPF/kernel code. [1] https://lwn.net/Articles/922405/ [2] sched-ext/scx#1624 Signed-off-by: Changwoo Min <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Schedulers need to know the energy model of a system to make energy-aware
scheduling decisions. The EnergyModel (energy_model.rs) represents the energy
model of a system. It loads the energy model data from debugfs (typically at
/sys/kernel/debug/energy_model), so the kernel should support not only the
energy model (CONFIG_ENERGY_MODEL) but also debugfs.
A system's energy model (EnergyModel) consists of one or more performance
domains (PerfDomain). A group of CPUs belonging to the same performance domain
is frequency-scaled altogether (i.e., the same frequency domain), so it has
the same performance-power characteristics. The performance-power attributes
of a performance domain are represented by a collection of performance states
(PerfState). Each performance state includes
the fastest CPU,