Skip to content

linux: fix cpu_freq() when one cpufreq policy affects multiple CPUs #2562

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

justeph
Copy link
Contributor

@justeph justeph commented Apr 16, 2025

Summary

Description

Some platforms (like RISC-V) only expose one cpufreq policy that manages multiple CPUs. This breaks psutil's assumption that each CPU has its own policy directory.

This patch reads affected_cpus for each policy and maps CPUs to the correct policy path.

For example on my bananapif3, I have:

root@bananapif3:~# cat /sys/devices/system/cpu/cpufreq/policy0/related_cpus 
0 1 2 3 4 5 6 7
root@bananapif3:~# ls /sys/devices/system/cpu/cpufreq/
boost policy0
root@bananapif3:~# cat /proc/cpuinfo  | grep processor | wc -l 
8

without the path, I have:

>>> import psutil
>>> psutil.cpu_freq(percpu=True)
[scpufreq(current=1600.0, min=614.4, max=1600.0)]
>>> psutil.cpu_count()
8

with the patch:

>>> import psutil
>>> psutil.cpu_freq(percpu=True)
[scpufreq(current=1600.0, min=614.4, max=1600.0), scpufreq(current=1600.0, min=614.4, max=1600.0), cpufreq(current=1600.0, min=614.4, max=1600.0), scpufreq(current=1600.0, min=614.4, max=1600.0), scpufreq(current=1600.0, min=614.4, ax=1600.0), scpufreq(current=1600.0, min=614.4, max=1600.0), scpufreq(current=1600.0, min=614.4, max=1600.0), cpufreq(current=1600.0, min=614.4, max=1600.0)]
>>> len(psutil.cpu_freq(percpu=True))
8
>>> psutil.cpu_count()
8

Some platforms (like RISC-V) only expose one cpufreq policy that manages multiple CPUs.
This breaks psutil's assumption that each CPU has its own policy directory.

This patch reads affected_cpus for each policy and maps CPUs to the correct policy path.

Signed-off-by: Julien Stephan <[email protected]>
@justeph
Copy link
Contributor Author

justeph commented Apr 17, 2025

Hi @giampaolo, I don't think the 2 errors from CI are related to my changes. Is there any thing I can do?

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.

[Debian unstable] 3 tests failing on several "uncommon" architectures
1 participant