Skip to content
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

Lime A64 runs all cores on max frequency #7

Open
rhpvorderman opened this issue Sep 28, 2021 · 6 comments
Open

Lime A64 runs all cores on max frequency #7

rhpvorderman opened this issue Sep 28, 2021 · 6 comments

Comments

@rhpvorderman
Copy link
Contributor

Hi, I noticed my A64 was getting quite warm. I found that it was running all cores at maximum frequency all the time.

Using cpufreq-info I found that its performance was mediated by the "performance" governor.

I debugged the issue and found that in the cpufrequtils service less /etc/init.d/cpufrequtils is started. This script tries to start the CPU by default with the "ondemand" governor. Unfortunately this governor is NOT available for the A64. Therefore it starts with the performance governor.

Solution is to create /etc/default/cpufrequtils with contents GOVERNOR=schedutil to set the governor to schedutil. This behaves similar to ondemand in that it schales the frequency based on the process scheduler (although ondemand is somewhat more aggressive).

@stefansaraev
Copy link
Collaborator

unfortunately, due to a workaround for allwiner's a64 timer instability, we can only reliably support performance and powersave governors. using any other governor may render the board very unstable (all cores at 100%)

however, you should be able to set performance governors max frequency manualy.

schedutil governor is also enabled in defconfig but we prefer not forcing it as default for now.

@rhpvorderman
Copy link
Contributor Author

Thank you for your quick response and the clarification. I found indeed that schedutil behaved a little odd, choosing the second lowest performance level instead of the lowest even when idle.
In my experience it is the "performance" manager that puts all cores at 100%. I am glad I bought the 20x20mm heatsink as that keeps the operating temperature acceptable even at the performance setting.

I put the timemanager on "conservative" for now. That seems to work well. The cores are mostly on 648 mhz. So that should save power. I hear you on it not being supported, but given the nature of the conservative governor it should be less susceptible to instable timers. I am willing to take the risk :-). If it starts behaving oddly I will use powersave.

If there is anything I can do as a user to help in solving this issue, please let me know.

@stefansaraev
Copy link
Collaborator

It is not that it isn't supported. if schedutil works for you, great (thats why we have enabled it in defconfig, there are use-cases..), just to use that. however - keep an eye on cpu usage. if all cores suddenly jump to 100%, you know why - and you may consider switching to powersave and adjusting min frequency.

I'll do more tests on schedutel in next few days, but I dont promise that we'll change defaults.

@rhpvorderman
Copy link
Contributor Author

I have to say I am a bit confused. The problem I reported was:

Hi, I noticed my A64 was getting quite warm. I found that it was running all cores at maximum frequency all the time.

This is due to the "performance" governor. But

using any other governor may render the board very unstable (all cores at 100%)

But that is exactly what the performance governor is doing and that is the default. As soon as you plugin the board with the olimage image it starts getting hotter and hotter as it ramps up all cores on 100% instantly. I don't mind if the defaults are not changed. I know how to fix this issue for my use case. I just want to report that running 100% on all cores all the time is the current default state of the olimage image. Is this the intended behavior?

@TsvetanUsunov
Copy link
Contributor

you can read here
https://www.olimex.com/forum/index.php?topic=7238.0
why this decision was made
it's a A64 silicon bug

@rhpvorderman
Copy link
Contributor Author

Thank you very much for this context. I see random dateleaps are expected when the frequencies are allowed to change, at least with the ondemand manager.

I will do some 24/7 testing with the "conservative" manager. That doesn't jump as much, so maybe that will prevent the issue? I am not running anything critical on the board and I do have physical access. So it is not a problem for me.

Thank you for all the quick answers. I don't have any more questions. I won't close the issue yet, as there is not a proper fix yet for this clock vs frequencies issue and other people might run into the same thing.

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

No branches or pull requests

3 participants