-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
CPU performance governor not effective after initial turbo/throttling #1469
Comments
I think your guess is correct. The arm currently needs to send a frequency request after the initial_turbo request has completed to stick. |
Lightspeed reaction, many thanks for looking into it. Reading through the issue on our repo again, I'm not even sure if throttling has the same result, as |
I don't think throttling will have the same issue as initial_turbo. I'll test it when fixing the initial_turbo issue (probably tomorrow). |
I've had a look and the issue is a bit more awkward that I assumed. This is the sequence: I'd assumed that cpufreq(performance) switched to 1500, but init_turbo clobbered that. The issue is the cpufreq driver reads the current frequency which it sees as 1500 due to init_turbo, and then skips setting it. I could imagine throttling causing a switch to the powersave governor to get lost, if when the frequency was throttled, it happened to match the desired frequency. I can't see how throttling could cause a switch to performance to get lost. As the cpufreq driver is upstream code we try to avoid hacking it. We may want to make the frequency reported to the arm not include init_turbo or throttling effects, but this needs some thought. |
I'm happy to change upstream code if the end result is cleaner, but I think we have some options before doing that. If we can confirm that the cpufreq driver is the first thing to query the core clock, and that it goes via the firmware clock interface, then I'd be tempted to get the firmware to lie the first time it is called and return either 0 or the minimum value. |
I think the issue occurs more than just once at startup. Throttling is another case. Another (hypothetical) case would be firmware side boosts. We don't want the kms driver's request for core_freq=500 to have been discarded as "we were already at 500". |
You're right. I think we should just delete the check, or if necessary replace it with a check that we aren't requesting the same frequency we asked for last time. |
The alternative is to only report to the arm frequencies it has set. Typically the arm doesn't know about throttled or firmware boosted frequencies unless it catches them by accident. e.g. /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq shows the frequency the arm last wrote, rather than the live frequency. |
That also works - we're changing the semantics of the mailbox call, but that sounds like an improvement. |
Enabled logging for cpufreq driver. I think:
|
This thread has gone cold - is there any reason not to change the mailbox semantics as outlined: to report only the values set via the mailbox? |
It's been started, but changing the api to allow "arm request" to be plumbed through had quite a long tail so it's not currently working. And I'm not at "pi" today. |
No problem - I know what it's like. |
firmware: vc_image_helper: Avoid misaligned exception due to uninitialised pointer firmware: arm_loader: Make arm clock accesses only see their own boosts See: #1469
firmware: vc_image_helper: Avoid misaligned exception due to uninitialised pointer firmware: arm_loader: Make arm clock accesses only see their own boosts See: raspberrypi/firmware#1469
@MichaIng can you test latest rpi-update firmware and let me know if it resolves issue? |
Yes, I can confirm it's working with current kernel/firmware |
kernel: overlays: Update display GPIO declarations kernel: Update hy28b-overlay.dts See: raspberrypi/linux#3880 kernel: net: bcmgenet: Reset RBUF on first open See: raspberrypi/linux#3850 kernel: ASoC: cs42xx8: Only define cs42xx8_of_match once See: raspberrypi/linux#3873 kernel: bcm2835-codec fixes See: raspberrypi/linux#3877 kernel: usb/dwc2: Set correct state on gadget disconnect kernel: USB: gadget: f_hid: avoid crashes and log spam See: raspberrypi/linux#3870 firmware: arm_loader: enable simple_fb iff there is a display See: raspberrypi/linux#3878 firmware: arm_loader: Mark V3D early boost as for the ARM See: #1469
kernel: overlays: Update display GPIO declarations kernel: Update hy28b-overlay.dts See: raspberrypi/linux#3880 kernel: net: bcmgenet: Reset RBUF on first open See: raspberrypi/linux#3850 kernel: ASoC: cs42xx8: Only define cs42xx8_of_match once See: raspberrypi/linux#3873 kernel: bcm2835-codec fixes See: raspberrypi/linux#3877 kernel: usb/dwc2: Set correct state on gadget disconnect kernel: USB: gadget: f_hid: avoid crashes and log spam See: raspberrypi/linux#3870 firmware: arm_loader: enable simple_fb iff there is a display See: raspberrypi/linux#3878 firmware: arm_loader: Mark V3D early boost as for the ARM See: raspberrypi/firmware#1469
Describe the bug
When using the
performance
governor for CPUfreq scaling in combination withinitial_turbo
, it does not become effective until e.g. a CPUfreq-related sysfs tunable is read or written to.The same was observed when the frequency got throttled (but is not throttled actively anymore, verified via
vcgencmd get_throttled
) due to low voltage, but that is harder to replicate repliably.To reproduce
initial_turbo=20
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
during the first 20 seconds of boot (while initial turbo is effective).vcgencmd measure_clock arm
for and beyond the next 20 seconds.Expected behaviour
After 20 seconds uptime, the performance governor assures max clock rate.
Actual behaviour
Clock rate stays at minimum/idle frequency, until, for some reason one reads or writes any of the sysfs tunables inside /
sys/devices/system/cpu/cpufreq/policy0/
.System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
cat /etc/rpi-issue
)? Seen on Raspbian Buster and Bullseyevcgencmd version
)? Seen on current stable#1327
and current master#1336
uname -a
)?5.4.51-v7+ #1327
-5.4.65-v7+ #1341
Logs
NB: The extremely low min/idle frequency was still applied in another testing context, but the same was observed with default
arm_freq_min
: MichaIng/DietPi#3719Additional context
With dynamic governors (
schedutil
,ondemand
, ...) it is not an issue. I can only guess that it is due to the fact that static governors likeperformance
basically set the frequency once and then go to sleep. If the firmware is overriding the frequency due toinitial_turbo
or throttling and then "releases" it again, it seems to not "inform" the governor to reset the frequency and it seems to not monitor such by itself (somehow reasonably). A dynamic governor re-sets the frequency frequently anyway, so there is no need to do that. Touching the governor tunables seems to trigger it re-setting the frequency, strangely not immediately but with a few seconds delay from what we observed.If my guess goes into the right direction, then I suggest that the firmware should somehow trigger the governor after turbo or throttling has ended.
The text was updated successfully, but these errors were encountered: