[Sony Xperia M] para22:
Interactive CPU Governor: Optimum parameters

Hello all!

I've been using this rom for about a month now and quite satisfied with it except for battery drain caused by cpu switching to max clock frequency 1.6GHz mostly. I've installed a huge number of apps, quite a few of which are really essential for me.

For quite sometime, i've been experimenting with CPU interactive frequency scaling governor and i'll try to list my results here...

by the way, a handy reference is from android source code

(*) https://android.googlesource.com/ke...7aebe08b/Documentation/cpu-freq/governors.txt

(*) http://bamboopuppy.com/android-cpu-frequency-using-interactive-governor/

(*) http://bamboopuppy.com/android-cpu-frequency-using-cpufreq-ondemand-governor/

Coming back to our original problem, I've still not figured out the effect of a few parameters, others i've listed below.

My main goal is to extend battery life while keeping phone responsive. As individuals use their phones differently, the parameters would also have to be tuned for "optimum" performance. The crater of "interactive" governor has already done a very nice job and allows various parameters to be set.

For this purpose, I'm using kernel tuner beta app from playstore.

Following parameters apply for Interactive CPU governor, which in my opinion is perhaps the best option we have for this kernel/rom combination.

Parameters

============

min_sample_time: 80,000(=80milliseconds) .

This parameter is used to average out cpu loads for scaling up/down frequency

boost:0, keep it to 1 would permanently keep phone's cpu to hispeed_freq (defined below)

target_loads:90

My understanding is that when cpu loads measured for min_sample_time exceeds this parameter, the cpu frequency in increased.

io_is_busy:0

to tune frequency when device is handling io requests. 1=>cpu frequency calculations include io requests, Generally IO requests don't need a cpu boost.

sync_frequency: 0

This relates to the minimum frequency the 2nd core is set to when up_threshold_any_cpu_load / up_threshold_any_cpu_freq (defined below) exceed the stated value. Setting this sync_freqency to 0 implies the second core is set to 0 when there is no load (saves battery by reducing current)

timer_slack:120000

basically to avoid cpu idle state at higher frequency, this parameter controls the time after which cpu forcibly checks if it is required to lower down the frequency if cpu is at idle state (even at higher than minimum frequency). Keeping it a little on higher side would prevent cpu frequency knocking up and down like a tennis ball. This allows the task at hand to finish, before cpu goes to a lower frequency.

hispeed_freq:918000

High speed the cpu you should go in case loads are high. if the loads are still high, it switches over to the next higher frequency only after the time specified in above_hispeed_delay parameter.

up_threshold_any_cpu_freq: 0

up_threshold_any_cpu_load: 0

Setting the above two parameter to zero, would put the minimum frequency of cpu core2 to 0 (ie offline). Thus battery is saved when cpu demand is less.

sampling_down_factor:10

CPU waits of certain time before switching to a lower frequency. If load is very high, CPU should stay at higher frequency, reducing timing overhead before switching down. Thus we can increase timer rate and cpu won't knock at different frequencies.

applicable at highest speed, thus related to batter drain. when more than one, decision to reduce cpu speed is deferred by the multiplying factor.

timer_rate:150000

the interactive governor rate [MENTION=2958093]which[/MENTION] sampling is done. less rate means more responsive (but also battery drain)

Currently, I'm not sure what should be the optimum rate. Please share your experiences.

above_hispeed_delay:250000

when cpu is at hispeed_freq, it waits for these many microseconds, before switching over to the next higher frequency. thus, if cpu is able to handle loads [MENTION=2909986]hi_speed[/MENTION]_freq, no need to go to higher frequencies and battery drain is avoided.

bootpulse_duration: 80000 temporarily switch cpu to highest frequency for this duration

go_highspeed_load:99 (?) on my phone i can't change this parameter. don't know why

===============================================================================

Please post your results with different parameters and its effect on performance vs battery so that we could all mutually benefit from a number of test cases. Immediate effects can be observed in cooltool.

Interesting parameters to observe are CPU frequency, cpu load (for both cores separately), battery mA current drawn. All of these are available in the form of 2d "gauges" as overlays on screen.

If there is any app which could plot/log cpu frequency, cpu load on the same graph wrt time, please post as that would be really helpful in understanding the effects of changing various parameters.

Currently, with around 240 apps, link2sd support and google play services enabled and very light phone call use ~30min-1hour/day, my phone lasts for about 1day, 9hours (average by GSAM battery monitor). I think the biggest culprits are wakelocks.

If we use android app ops, many background services keep on restarting. The main culprit is android permissions, which is very badly implemented compared to others like that in iOS or BlackBerry 10 OS etc.

Even with a decent 1700mAh battery, phone doesn't last 2days :(

However, at least by optimising these parameters, the phone is very responsive. There is no dialer lag yet the phone doesn't bake like an oven and battery charge lasts one day .

Also, another huge battery sucker is dex2oat which is android elf(java bytecode to native library) compiler. I don't why it needs to run everytime even though I am using ART runtime.