[Nexus 4 Original Android Development] Hanny:
The recent posts about adding a third interactive governor state have inspired me to think, and i want to share some of my thoughts.

First lets clarify what currently going on in r125, in some easily understandable words:

When there is 1 core active, the interactive governor is using the Power-Saving Tunables - which is more conservative than the defaults in r122

Possibility A:

When the load goes above second_level (default=25), 2nd core goes active, and the interactive governor is still using the Power-Saving Tunables

When the load goes above second_level again, 3rd core goes active, still using the Power-Saving Tunables

When the load goes above second_level once more, therefore the transition from 3 cores to 4 cores, the interactive governor will automatically switch to Performance Tunables - which is much more aggressive than the defaults in r122 - and is tested to be drastically increasing the performance of games and benchmarks

Possibility B:

When the load goes above first_level (default=90) , therefore the transition from 1 core to 4 cores, the interactive governor will directly switch to Performance Tunables

-----------------------------------

There is currently one report of seeing microstutter in gallery opening-image animation.

I like focusing a lot on details, especially transition animations. I do not see that in the gallery, but for the Notification-Press Microstutter, the situation is the worst at the beginning of the hotplug driver -> not noticeable anymore in r122 -> but in r125 i see some of it (although its still better than the ones before and on r121)

What is Notification-Press Microstutter I see? after pressing on notifications like gmail or whatsapp, the transition animation of the status bar automatically pulling up, is not completely smooth from the bottom to the top, but rather seeing it stop at the bottom, and directly goes to the top without seeing its journey in between. (of course talking about within 0.5 second or so)

------------------------------------

No matter what microstutters we are talking about, the Power-Saving Tunables might just be a little bit too conservative, although I understand its completely for battery-saving.

Some have stated that putting an extra state during the transition of [1 core -> 2 cores] and let it stay until [3 cores -> 4 cores] when the Performance Tunables kick in. Therefore during the course of 2 cores / 3 cores activating, that extra interactive governor state is being used. The reason - For better UI experience? etc etc...

Of course for the suggestion about Performance Tunables loading for a while -> back to some not-that-aggressive-tunables, I am not agreeing with that, because all of us want consistently high responsiveness during our game/benchmarks no matter how long we play them.

--------------------------------------

But lets think about this:

1 core -> Power-Saving Tunables

2 cores / 3 cores -> an extra state (for example, a moderate one, r122's default)

4 cores -> Performance Tunables

is that right?

The occurrence of any microstutters is because of

the delay between idle -> your execution of the task

, let it be opening a photo in gallery, opening an app, or pressing on a notification. During idle, its 1 core, so why improving the responsiveness of 2 cores / 3 cores?

At this point, thinking of the reverse, I have come up with a suggestion:

1 core -> an extra state (for example, a moderate one, r122's default)

2 cores / 3 cores -> Power-Saving Tunables

4 cores -> Performance Tunables

Explanation:

During 1 core, the phone is idle, i.e. no tasks is stressing the phone. If we have a moderate timer_rate it just polls / respond to the load more frequently, but it is idle and no load, so even if it polls faster, it should not bump up to unnecessary frequencies and waste juice. And if it polls more frequently, we have the benefit of the increased responsiveness when we suddenly put some load on the phone during its idle, and possibly eliminate any microstutters we may see.

During 2/3 cores, we are utilizing multi-cores of the Krait CPU, with a light-usage (because heavy usage will make it 4 cores). Therefore we don't need so much responsiveness and we are already constantly interacting with the phone, which means no idle->sudden task and no chance of microstutters. At this point we can save some juice by having some more conservative tunables to prevent the CPU being bumped up to unnecessary frequencies.

4 cores, needless to say, its heavy and fast. very cool.

-----------------------------------

1 core more responsive? idle to sudden load? Don't we have touch_boost already?

To the best of my knowledge, we need to move certain pixels to fully activate touch_boost and its intention was used for extreme-smooth scrolling (of course excluding tapatalk). The original idea of the need to move some pixels instead of boosting it right away when we touch, is because we dont want to waste unnecessary bumps if we are just touching/holding on an empty area of the screen which does not really do any task or any load. Thats a good idea.

However, the reported gallery incident, and my observable notification press thing, does not require moving of pixels. It is just a press. It conflicts with the above principle of preventing "just a touch" -> boost the cpu. So in this case we need the governor to decide whether we should have some high frequencies when its "just a touch". If during 1 core we have a more responsive governor tunables, then it favors both of our needs of higher frequencies - scrolling (no matter what) and "just a touch" (only when necessary).

Correct me if I am wrong in anywhere in this post. Thanks for the time reading :D