[Nexus 4 Original Android Development] Hanny:
oh its boosting for less than 1/10 second now? yea i thought about such "boosting time" either but figured nowhere to touch that, its still not in the userspace right :) looking forward to see the effect, maybe we can try 200ms first to see if it really helps, then start decreasing for the sake of battery

also, how long does the swipe-boost (2 cores) stay? is it determined by the same min_sample_rate as well?

now by thinking for a while i have a little idea, if you guys dont mind me proposing a change just after some changes have been made :p

the majority of my observed stutters comes from after pulling down notification bar and pressing a notification(then an app opens) or the settings button in quicksettings panel (tried multiple times in a single boot to ensure not first time cache issue)

then i try to make system monitor window and peak through the transparency of the pulled down notification bar and see the cpu behaviour while i am making the presses. with the currently 1 sec update interval, i can barely see that even the swipe-boost(2 core is still in effect, the stutter still occurs, but not everytime, its occasional. then i think, would it be the frequencies?

I took a look at the dynamic interactive tunables, its pretty good, the profile of 2-3 cores has 30k timer rate and 20k min sample time, well a possible little improvement here might be increasing the min sample time just abit to 30k. but i came up with a more wild idea...

firstly i thought about the necessity of the state of "3 cores" - it requires 4 seconds of delay from 2 cores to 3 cores under second_level load but the only function of that i think would be the transition / bridge from 2 cores to 4 cores during tasks / games that does not go above first_level but constantly stay at the mid-high load. there is no benefit for UI interaction cuz its usually suddenly fast and furious, and then idle.

So actually i think this can be replaced by another condition (not sure if feasible or not) for 4 cores that if first_level is reached OR a load is stayed above [mid-high load e.g.60] for X seconds then directly go 4 cores. some pages ago someone said a game on his phone lags at the beginning but smooth at last thats probably because the 4sec x3 delay from 1 core to 4 cores of the current logic, but if we set the X above to 5 seconds then it saves 50% of the time for 4 cores tl activate at the right time.

besides dealing with the unnecessity of the 3 cores state, it also sets the ground of the below so that no more than 2 cores will be used the the below scenario to avoid extra battery loss

back to my stutter, during 2 cores the interactive tunables are still using go_hispeed_load 99 at 1512 and apparently franco sets this for battery conservation. however i still remember (apologizes if i rmb wrong lol) that UBER and some others would like to have lower go_hispeed_load and a lower hispeed_freq for the sake of the state that the phone is preparing for higher loads coming next instead of oh there is load so increase frequency. I think this is the main cause why even at 2 cores the animation still isnt smooth after pressing a notification or settings button.

apparently mpdecision bumps to 1512 and prepare itself for any possible higher load. thats surely a battery waster but we might try 1350 or something with a considerably lower go_hispeed_load, instead of the current situation that it goes to 1026 or 1188 AFTER load is stressed.

at the very beginning franco uses 99 go_hispeed_load for overall battery conservation but i think it might be time for us to make some great use of the capabilities of dynamic interactive tunables. at last the screen-on-touching-nothing (reading etc) or touch-but-not-swipe (keyboard) state will still be stable and power-conservative.

well but if this is not plausible to take into practice, i think my next suggestion would be a higher swipe-boost frequency as the current 702 is not enough for cache-dependent like settings or whatsapp or even gtalk. however i just dont want that higher freq to be forced everywhere on any swipe therefore i tried to make use of the go_hispeed_load.