[Galaxy Note II Android Development] mat9v:
Let's begin with

LULZACTIVEQ

governor as it is the one I have chosen to use for my scripts. This governor was created by [MENTION=4486415]robertobsc[/MENTION] by modifying lulzactive governor for use in Galaxy S2 and S3 phones, from the mouth (so to speak) of the creator more info can be found HERE.

Lulzactive is based on interactive governor with "hotplugging logic built in". It has a lot of configuration options and while that may suggest it has a lot of variables to check while making any decision it really is not that complicated. Some other governors just make decisions without any possible input from the user with some values hard coded, so not much is changed in terms of overhead.

Generally this governor works the following way:

- periodically check the cpu load

- based on that decide if increase in frequency is needed ("inc_cpu_load" defines at what cpu load level frequency should be increased) or maybe decrease is better at the moment (defined in "dec_cpu_load")

- here comes hotplug part

- if the frequency is high enough ("hotplug_freq_1_1" to "hotplug_freq_3_1" set levels at which next core is brought online) additional cores are powered up and the load is shared between them if possible (multithreading) or maybe powered down if the frequency falls below certain value (decided by "hotplug_freq_2_0" to "hotplug_freq_4_0")

- on top of that the core will not be brought online if "queue length" is not long enough - queue length is a value that tells how many things must be waiting to be processed to meet the condition - they are defined in "hotplug_rq_1_1" to "hotplug_rq_3_1" for conditions to enable cores 2-4 and in "hotplug_rq_2_0" to "hotplug_rq_4_0" for conditions to disable cores 2-4

- "pump_up_step" decides how high to jump on detecting the need to increase frequency - it defines how smooth should the increasing the frequency be happening

- "pump_down_step" in mirror decides how much to decrease frequency if there is not enough load

- "hispeed_freq" is a special setting that comes into effect if very big loads are detected as in for example starting benchmark :) - it enables cpu to jump directly to the defined frequency, for me it is a max frequency for the script class - max frequency the cpu is allowed to run at all -

this option is the main culprit in stability problems with undervolting because it causes the biggest spikes in voltage when changing frequencies from say 200Mhz straight to 1920Mhz

- change that to 1000Mhz and you probably can jump another UV step :)

- "screen_off_max_step" - decides what is the max frequency the cpu can work at when screen is off

There are many other settings that are user configurable, but frankly I can't measure their impact on battery and their impact on smoothness is too hard to detect so I leave them alone.

For example "hotplug_sampling_rate" decides how often to check if maybe cores should be brought online or turned off - it can create some problems because constant turning cores on and off costs battery, much more then keeping them idle for a moment longer in case they are needed.

My governor config differs quite a lot from defaults and here is why I have it configured like that:

- I prefer highly reactive config meaning when the load is detected I jump to higher frequency quickly to deal with load (by 5 steps, from 200 to 700Mhz) while normal config would go from 200 to 400 to 600 - those two ways of doing things are based on assumption that most load situations can be dealt with with small increase in frequency or (my way) they can not and require more speed to take care of things. Standard way would have you going up slow and turning next core quite quickly, I on the other hand jump to 700Mhz to deal with load and if it's not enough go to 1200Mhz (at 1200Mhz it is possible to have all 4 cores enabled as decided by "hotplug_freq_3_1" if there is enough work to do - decided by "queue_length"). That way is battery friendly as it mostly uses one core to deal with load and only turns on additional cores when really required - it has one caveat though as sometimes user interface may be a little jumpy when in addition to doing something like sliding or changing desktop pages an app is starting or updating in the background. For those that feel this jumpiness and it's annoying I have created "ultrasmooth" script addon that relaxes those settings in enabling additional cores to start sooner.

Normally it works like this:

Depending on script version, on normal load (over 60% at current frequency), the speed jumps up 5 grades - from 200Mhz to 700Mhz, if load is still exceeding 60%, jumps again to 1200Mhz and again to 1700Mhz. If first jump is not enough to deal with load and jump to 1200 is executed, second, third and fourth cores are powered up (that also require a certain queue length to be filled before they come online and ensures that short bursts of load do not needlessly power up additional cores). Basically on initial load - from 200-300Mhz - I'm turning cores later than in default config, because it happens once the frequency reaches 3rd hop (1200Mhz).

Consequently, my script asks for swift clock down of the cpu. From current maximum go down 4 steps if utilization is below 50%, then next 4 steps, test again, next 4 steps - along the line cores are turned off.

In ultrasmooth version:

Start at 200Mhz, on detected load jump to 700Mhz (at 700Mhz it is allowed to have 2nd core turned on if queue_length is met), if required again jump to 1200Mhz (by that time both 3rd and 4th core can be enabled if queue_length requirements are met). Now that all cores are powered up we can jump to 1700Mhz and higher if required. Clocking down works as in original, only cores are powered down later, else the settings would interfere with powering up sequence.

Other governors information will come later when I have a time to work on that (I do not want to copy and paste without knowing what I'm talking about).