AIDA64 (Android hardware info app) shows that not only the six slower A55 (1.7 GHz) cores never slow down below 1.2 GHz but the two more powerful A77 cores run at their top 2.0 GHz frequency all the time.
Which not only results in such a terrible power consumption but also in worrying termal conditions (AIDA64 gives temperature readouts of not just the battery but also CPU, GPU, modem, SoC, camera, etc.)
Just a super dirty test; by setting powersave as the frequency governor, I’m getting frequencies of 768000 (6x) and 300000 (2x). So the hardware support is there, but the settings could be tweaked further it seems.
Another yolo test: setting the governor to ondemand yields the lowest frequencies when idling, but boosting rapidly when needed:
echo -n "ondemand" > /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor
where cpuX is cpu0, cpu1 … cpu7.
The default values were schedutil for cpu0…5 and performance for cpu6…7.
I’m testing ondemand for a few days or so, to see if there’s any observable difference. I don’t have any monitoring going on, so perhaps e.g. @DrDweeb could try this out? At your own risk, obviously, but it seems to work for me 
In theory schedutil was supposed to be the replacement for ondemand, that is even more aware what is the device doing. Like Energy Aware Scheduling seems to only be available for schedutil. On the other hand even with continuous efforts from Intel and AMD it proved to be unreliable and leading to much worse performance on x86, even worse than powersave, and much worse than ondemand.
On ARM it is supposed to be better, but I can’t find any benchmarks comparing that. So it might be interesting to set all the cores to ondemand instead of schedutil, as in theory it is the “smartest” scheduler.
Edit: Also, why are Gold cores set to performance on SFOS? It seems all cores should be schedutil, that is how they are set by Sony: https://github.com/sonyxperiadev/device-sony-lena/blob/master/rootdir/vendor/etc/init/init.lena.pwr.rc#L76
Maybe that is why the power draw is higher, performance is definitely not what we want for powersaving?
Perhaps the schedutil metrics are not functioning correctly on X10III… So far ondemand hasn’t resulted in any stuttering or anything else negative. Heck, even with powersave on all eight cores is enough to keep the device responsive! It’s a powerful device indeed
That is a good question. I checked the link, and it looks like while the device is on charger, the cores are set to powersave, but they are the same (6x sched, 2x perf). That doesn’t make an awful lot of sense… Perhaps this should be wrapped into a separate bug report?
Regarding voicecall-ui, it’s still an issue, at least on the XA2. Short version: after each incoming call, voicecall-ui wastes CPU, causing batery drain. Same issue on the 10-iii?
Voicecall-ui seems to be still an issue on the 10iii.
Regarding the CPU settings, also the lower scaling frequencies are not active on the 10iii. Still the same as on the XA2.
I set all cores to ondemand governor, and set tbe lowest frequency to 300000 maybe there is an improvement, but i doubt it. We will see.
How are you measuring the frequencies? If it is getting maximum of any core then I assume the problem is Gold cores are on performance, and setting tjem to schedutil should help in similar way.
The question is if schedutil or ondemand is better, that is what we need to test. On idle I can’t measure any meaningful difference.
I’ve noticed this problem on my 10iii when wifi is enabled – quick drain by end of day. If I keep my internet connection limited to cellular data, I can get 2-3 days of battery life. Just another data point if helpful.
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
shows the lowest frequency used by the current governor.
cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_min_freq
shows the lowest available frequency of the CPU.
The lowest cpu frequency is 0.3Ghz, but the governor only scales down to 0.65Ghz, if i remember correctly.
But playing around with the governor or finetuning their settings normally will only get you small to non noticeable differences.
I think the problem is that the cpu cores are leaving their sleep state too often.
So this explains why cpu6 and 7 cores run at max frequency of 2.0 GHz most of the time… Let’s see what kind of improvement I can get from switching it to either schedutil or ondemand…
P.S. And the next test will be to switch all the remaining cores to ondemand, too.
Hmmmm… while ondemand seems to work reasonably well (scaling frequencies as load rises) on cores 0-5, setting the Gold cores to ondemand causes that the CPU stays at 300 MHz nearly all the time. I’ve only seen it switch (all the way up to 2 GHz) a few times and only for a second or so. Even video playback or audio streaming doesn’t affect it.
Yeah, I noticed the same. But I can still watch videos and browse the Internet smoothly even with powersave, so I think it’s working correctly. I’m thinking about using conservative as my next test value; it ramps up the clocks more slowly.
On thing I’ve notice what you set for cpu7 applies to cpu6 and what uou set for cpu5 applies to cpu0-4, it looks like there is only 2 governors one for each class of core.
May very well be. I didn’t even check; I just made a batch that sets it for all of them.
It is defined in affected_cpus file which other cores are also affected by that core’s governor setting. So by modifying that file it can be changed.
I’ve just rebooted the phone and governors of all cores were reset to defaults. And so were minfree values in /sys/module/lowmemorykiller/parameters/minfree.
Is it supposed to be like that? Guess I’ll need to create some script to re-set them to what I like after each reboot…
Did anyone tried doing echo 300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq , so cores can go down to 300MHz? It would make sense, to improve idle.
Also, I really suggest to use schedutil instead of ondemand , it is the most “clever” scheduler, most commonly used, the default for Sony on Android, and can be tuned, which we could try.
Done. Silver cores now indeed go down to 300 MHz. So far I haven’t noticed any negative consequences of doing so when using the phone. No noticeable slow downs, etc. I will check if it has any positive impact on battery life in idle/sleep and I’ll report soon.
Here are my SystemDataScope Logs of the last 30minutes. I was taking my dog out for a walk and used the phone stayed in my pocket most of the time. Only mobile data was on.
What do all those graphs tell us?
It shows that the phone switches between the set frequencies of 1248 an 2047Mhz depending on load. Most of the time the cores are in their C2 power save mode.
The interesting part is the cpu sleep graph. This is way too low. It should be around 90 or above when the phone is not used. The constant wake up of the cores is causing the battery drain.
Back in the days with my Sailfish Port for the Nexus5, it als suffered from battery drain. I compiled kernels with more power saving features, different CPU governors and fiddled with their settings. All this work only saved a few percent of battery life at the end of the day.
Finally we found the issue…the problem was that bluetooth, even if not in use constantly woke up the cpu and which lead to the battery drain.
So i think, all those fiddling around in the cpufreq folders will not solve the problem. Something is waking up the cpus too often, this could be the kernel or a part of SailfishOS.
Maybe installing powertop and doing a long time report could reveal which causes this issue.
