[Nexus 4 Original Android Development] Hanny:
Thanks for the sunday lesson :D love learning from you

If I get it right, r70 is using 2-3 seconds to complete a set of operation deciding for the on/offline of 3rd and 4th cores, and r82 is having 1/10 of the jiffies delay therefore it uses 0.2-0.3 seconds to complete the same set of operation with the exact same hotplugging thresholds.

Just made a GTA test with throttling mode for monitoring the frequency of the 3rd and 4th cores online on r82, as reported by PerfMon.

Every 2-7 seconds (most commonly 4 seconds), the 3rd and 4th cores show online (regardless of utilization and frequencies) for 1-3 seconds (most commonly 2 seconds)

While Perfmon is refreshing its panel in the interval of exactly 1 second, it is capable of monitoring the 10x slower timers on r70 as it needed a few seconds to finish through the entire hotplug decision operation. Furthermore just because it requires so much time to complete an operation cycle, the 3rd and 4th cores stay on until the next scheduled work, and during the delay the load was just enough for another online call thus the two extra cores is shown staying online all the time on r70.

And the different story on r82 is that during the 1 second refresh interval of Perfmon, there are probably completion of 2-3 sets of hotplug decision operations, therefore some 0 utilization or 0mhz frequencies may be shown as it is just at the moment while the cores are operated to go online or offline. Also based on the aggressive timer, there are more load detections therefore an increased chance of being detected as "lower than threshold", thus offlining the two extra cores. And while this happens it is displayed on Perfmon then making me think that the cores are continuously offline for a few seconds but in reality it may not.

That explains why the FPS has risen on r82 from r80 because during the milliseconds Permon is not reporting the CPU statuses, the cores might have been online to help working.

It drives me to the curiosity of why the timers have to be set to this aggressive (or in other words, actively polling the load and make operations)? That would be definitely helpful for "onlining cores extreme-immediately while the load increases" to improve responsiveness in peak-loading times during daily app operations. On the other hand the cores might as well be offlined extreme-immediately while the load decreases. That saves some extra juices for sure as while each time saving 1-2 seconds leaving the two extra cores on, one day it will be thousands of seconds thats the power consumption of onlining two cores constantly for ten minutes.

But seems like I have read before while you decided to test pure-quad-core mode, hotplugging frequently would affect performance, and is noticeable if its a continuously-high-load task like the heavy games. Is that a trade-off (while battery is conserved at the first place) between UI responsiveness and constant-gaming performance? Then I guess your auto-locking idea would be the only way out at the moment, before our GPU load are being able to be polled!

:cowboy: -> :) (I believe this means hats off to you)

Oh and I've forgotten to give feedback about the colors on r82 - I am a default-gamma-stayer, on r80 the default colors were "being washed out" (assume you dont regard default colors are washed out originally)... and it is because of the limit set in saturation, which the 80 is being limited to 7. Now the default colors get more saturated again to the level I prefer the most :good: