Skip to content

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 2 commits into from
Apr 4, 2025

Conversation

multics69
Copy link
Contributor

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.

@multics69 multics69 requested review from arighi, htejun and hodgesds April 3, 2025 15:39
@multics69 multics69 force-pushed the lavd-energy-model branch from ba5a79e to c016769 Compare April 3, 2025 15:41
Signed-off-by: Changwoo Min <[email protected]>
@multics69 multics69 force-pushed the lavd-energy-model branch 3 times, most recently from 94addbf to 2b121bb Compare April 4, 2025 01:42
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]>
@multics69 multics69 force-pushed the lavd-energy-model branch from 2b121bb to 9c9fd2b Compare April 4, 2025 01:47
@multics69 multics69 added this pull request to the merge queue Apr 4, 2025
Merged via the queue into sched-ext:main with commit 0f22705 Apr 4, 2025
30 checks passed
@multics69 multics69 deleted the lavd-energy-model branch April 4, 2025 02:08
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants