Skip to content

scx_utils, scx_lavd: Add cpu_capacity to Topology and use it in scx_lavd. #1465

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
Mar 7, 2025

Conversation

multics69
Copy link
Contributor

There are various sysfs sources that somehow represent each CPU's capacity even if the kernel does not properly implement arch_scale_cpu_capacity(), which is used for scx_bpf_cpuperf_cap().

This PR tries to make a best guess about CPU capacity based on available sysfs entries by checking the most precise (e.g., vendor-specific information) to the least precise (CPU max frequency).

Also, scx_lavd is changed to use cpu_capacity exposed by Topology.

@multics69 multics69 requested review from arighi, htejun and hodgesds March 7, 2025 01:09
@multics69 multics69 marked this pull request as draft March 7, 2025 01:39
@multics69
Copy link
Contributor Author

Ooops, it fails in our CI. I will take a look.

@multics69 multics69 force-pushed the lavd-cpu-capacity branch from ddf6320 to e8d4260 Compare March 7, 2025 01:56
Changwoo Min added 2 commits March 7, 2025 11:12
Try to make the best guess of CPU capacity by reading various sysfs sources
from the most precise to the least precise in the following order:

  /sys/devices/system/cpu/cpuX/cpufreq/amd_pstate_highest_perf
  /sys/devices/system/cpu/cpuX/acpi_cppc/highest_perf
  /sys/devices/system/cpu/cpuX/cpu_capacity
  /sys/devices/system/cpu/cpuX/cpufreq/cpuinfo_max_freq

The capacity value of each CPU is scaled to 1024.

Signed-off-by: Changwoo Min <[email protected]>
Instead of guessing CPU capacity using a CPU's max frequency, rely on
cpu_capacity information from Topology, which is best guessed from
various sysfs sources.

Signed-off-by: Changwoo Min <[email protected]>
@multics69 multics69 force-pushed the lavd-cpu-capacity branch from e8d4260 to 3ebc165 Compare March 7, 2025 02:12
@multics69 multics69 marked this pull request as ready for review March 7, 2025 02:31
@multics69
Copy link
Contributor Author

Ooops, it fails in our CI. I will take a look.

Fixed.

Copy link
Contributor

@arighi arighi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Few comments.

The static approach works in most of the cases, but in some architectures the capacity can change at runtime (see for example #1207). In general it'd be nice to have an event-based API to catch topology changes. But I'm not sure how to implement something like this.

Or maybe just have an API similar to scx_bpf_cpuperf_cap() to get a more accurate capacity value, see for example get_actual_cpu_capacity() in fair.c, that takes in account the cpufreq pressure, thermal throttling and potentially other factors.

But this is not related to this PR, just some thoughts for the future.

@multics69
Copy link
Contributor Author

multics69 commented Mar 7, 2025

That's definitely a way to go. Thanks for the suggestion.

@multics69 multics69 added this pull request to the merge queue Mar 7, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 7, 2025
@multics69 multics69 added this pull request to the merge queue Mar 7, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 7, 2025
@multics69 multics69 merged commit 0543264 into sched-ext:main Mar 7, 2025
97 of 140 checks passed
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.

2 participants