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?
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.
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.
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.
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.
I set the governors to ondemand, and set the min frequency to 300000 for all cores. I am getting readings of 6x 576000 and 2x 300000 even when ran from on device terminal, screen on as usual. With Bluetooth active and Nettiradio playing, the silver cores sometimes go up to 1Ghz. I don’t see much wrong here in my case…
Wow, I just found a typo in Sony’s source code. Turns out the minumum frequencies should be even higher! Because of a typo minfreq is not set for the gold cores, it defaults to those 300MHz, while it should be set to 652800.
A few lines above in that file there is minfreq set for the Silver cores too, where they raise it from the default to 576000. I really wonder why Sony does that.
