[Nexus 4 Original Android Development] Hanny:
Thanks for the app update franco, saw it when I woke up and that's really amazing.

One suggestion though: the description for cores_on_touch should be swipe, instead of touch, to avoid confusing the users, am i right?

I am apparently not a power mode user, but I've tried the four of your power modes to have some inspiration.

The first thing I've noticed is that, even with the Slightly Speedy mode, the hispeed_freq is still 1350 (with 1512 max freq), while only with Powerful Performance it is 1512 (with 1512 max freq). Nevertheless our kernel default is currently with hispeed_freq 1512, so is that going to get down further? I'm inspired by this, and wanna share my thoughts with other folks as well:

(yeah ive talked to u about two of them last night but ive got some more this morning :P)

For me, sometimes an intense gamer, and a lover of smooth UI interactions, dynamic_scaling is absolutely essential to me. Therefore these suggestions are targeted directly at the dynamic tunables.

And I have a principle when making decisions: We put user experience the first, and put background calculations / tasks the last (as they aren't noticeable anyways), while favouring battery conservation as much as we can.

Originally, interactive governor is used for more interactivity and responsiveness. However, when we got the input_boost working (mpdecision started such thing as well but in a much more aggressive way), we have already been, and should further change the way we use the interactive governor.

1 Core

​

With dynamic scaling, and the boosts, we can choose our priorities for the user. The governor? used to suppress frequencies as low as possible when there are no interaction (no demand of user experience) and save battery.

First of all, hispeed_freq can be scaled down to 1026, of course not talking about power modes, but with the kernel defaults (frequency range: 384/1512). Because if there are 99 load during 1 core and is NOT triggered by a touch, its probably background calculations.

Then, timer_rate add 10k, 20k, or even double the current 30k and make it 60k. A lower timer_rate is originally for detecting the demand of user experience as soon as possible, but when input boost is boosting the frequency immediately when a touch is registered, it surpasses the responsiveness of timer_rate and therefore timer_rate can be made much higher to prevent a lot of unnecessary frequency jumps, and favour screen-on-idlers like ebook readers or movie watchers.

In exchange, we can favour user experience by tuning up the input_boost_freq from 1026 to 1350.

2-3 Cores

​

hispeed_freq on this can remain 1512 because UI tasks can be hard sometimes when 2-3 cores are used.

However, another feasible choice would be UBER's manual setup (95 go_hispeed_load + 1350 hispeed_freq), as UI interactions sometimes might not reach 99 load, and 99 go_hispeed_load only favours the device's heavy load but not user experience, while with 95, it is easier to respond to user interactivity.

timer_rate we can add 10k or 15k to this, for the same reason as above, with swipe boost.

In exchange, we can favour user experience by tuning up the swipe boost frequency (yeah, 2 cores) from 702 to 1026.

4 Cores

​

As mentioned to you yesterday, the improvement for 4 cores would be the possibility of kicking in the performance tunables after 4 cores has stayed up for X seconds (I suggest 10), to prevent accidental 4 cores battery usage in UI interactions, while remaining the ultimate performance for gaming and benchmarks.

So to sum up, we can prevent unnecessary and unnoticeable frequency jumps / high frequencies as much as possible, and give the priorities of high frequencies WHEN a user touches the device and demand for smooth experience.

Finally, for you guys' suggestions,

I think that franco is planning to allow the possibility of customizing the dynamic tunables, as he hinted before, therefore he is not hiding them, and I believe he can sort the min_sample_time thing out soon...

and to franco, may I also hope for the possibility to customize the swipe boost frequency, along with cores_on_touch? Then we will have full control over the two boosts.

Thanks for reading as always :D