- Jun 7, 2015
Couple of weeks ago, Joshuous wrote a new feature, namely Dynamic SchedTune Boosting, that’s been incorporated in recent RenderZenith kernel builds, which essentially alters the value of schedtune.boost for the top-app cgroup dynamically on touch events, to conserve battery. But still, the solution was not that flawless, since it didn’t migrate the task to the big cores when essential as Joshuous previously explained. A quick workaround was to increase the value of /dev/stune/top-app/schedtune.boost to 1 (at least) to allow the utilization of the big cores when required. Many of you may be wondering why that was necessary. Well, hopefully I can break it down a bit for you.
Given the task that needs processing, the find_best_target() function – that is responsible for placing the tasks on the suitable cluster – iterates firstly on the big cluster when the SchedTune boost value is greater than 0, whereas the little cluster will be iterated firstly, should the value of SchedTune boost be equal to or less than 0, to save power. What SchedTune boost does is inflating the task and CPU utilisation fed to the scheduler, and therefore impacting the OPP selection and allowing the task to be placed on the big core(s) if needed. What the older version of Dynamic SchedTune Boosting did was rather inflating the value of utilisation going into Schedutil governor, that is then used to determine the frequency step to be selected for the task via a linear formula, which consequently increases the calculated frequency. But since the value of utilisation going into the scheduler is not inflated, the placement of the task on the corresponding core(s) won’t be impacted and therefore, the task won’t be moved to a big core instead. In essence, the older version would only increase the frequency and not impact the tasks placement on the cores. This caused a drastic performance difference compared to what you get when setting the SchedTune Boost value statically.
With the new v2 version, Dynamic SchedTune Boosting will directly change the value of /dev/stune/top-app/schedtune.boost directly, addressing the issue of only inflating the utilisation data going to the schedutil governor, and therefore the tasks should be able to move to the big cluster when demanded as well as increasing the CPU frequency. This will allow us to safely leave the value of /dev/stune/top-app/schedtune.boost at 0 and save some power for low-medium workload scenarios, since the tasks will be moved to the big cluster on touch with no issues.
Very well explained Mostafa
And thanks for saving me the time
To add on, don't be alarmed to see /dev/stune/top-app/schedtune.boost having the same value as dynamic_stune_boost when you want to edit it because your touches trigger the boosting. Just write the value you want into the file and save. It will automatically update the default stune boost value when the boosting stops. To confirm it, you can connect your phone to computer and do
adb shell cat /dev/stune/top-app/schedtune.boost
to confirm that it has changed. You gotta wait a second or so before you issue that command.
I would recommend keeping the /dev/stune/top-app/schedtune.boost at 1 or higher if you want lower latency when Dynamic Stune Boost kicks in. Reason being that default stune boost of 1 somewhat ensures that most of the top-app tasks are already on Big cluster so that we don't have to suddenly migrate too many tasks from Little to Big when Dynamic Stune Boost kicks in.
If you don't type much, and watch videos or listen to music mostly, then setting default stune boost to zero may save you more battery