So I promised a thorough write up of what was done and why it was done on my last post of governor tweaks. Thats what this is:
I tuned the cpu_down_rate to 10. I lowered this number because a lower number of samples will be evaluated to execute the scale down logic. A higher number here will result in a delayed scale down, where as a number too small can cause the cpu to scale down too fast and cause the MHz to drop before load is completed. This is the same thing that I did to cpu_up_rate. The smaller number allows the cpu to ramp up faster to reduce lag. The down_differential was tuned to 2 because after spending sampling_down_factor*sampling_rate micro seconds at maximum frequency on high load, governor samples the load again to calculate an approx target frequency to scale-down-to which should not trigger up_threshold in the next sample. (Triggering up threshold may cause jumping to max frequency again). The hotplug_freq_1_1 was set to 800000 (800mhz) this is where the second core is going to turn on, hot_plug_freq_2_0 was tuned to the same 800mhz, this is where the second core turns off at scale down. I have found that up to and about 800mhz a single core is all that is necessary to handle most tasks, and above that a second core will help complete tasks faster. We dont need to worry about the other hot plug freq settings as these are for core 2 and 3 which we dont have. ignore_nice_load is where you tell the cpu to ignore the "nice loads," these are loads that are considered low priority by the scheduler. This prevents the cpu from scaling up because of a wakelock or something like a service that doesnt require a lot of resources. sampling_down_factor acts as a multiplier for sampling interval for re-evaluating the load when CPU is truly busy and is on highest clock frequency. If set to 0 this will cause the cpu to drop to lowest frequency even during heavy load resulting in lag. Thats why it is set to 1. up_threshold measured as percentage, when load on CPU is equal to above up threshold, CPU is scaled Up. Lower value - early scale up, and vice-verse, and is set to 50%. up_threshold_at_min_freq this threshold is used as up threshold while sampling at frequencies less than freq_for_responsiveness. Above that, normal up_threshold is used. This gives us an option to make scaling aggressive/relaxed until a frequency and normal for higher frequencies. I have this set to 90% ensuring that there is sufficient load on the cpu before scale up is triggered. We dont want the cpu jumping to max freq like a true ondemand. So now with this information we can see how the processor is going to keep cpu1 offline until it reaches 800mhz, and until it reaches that freq the governor is going to make sure that there is sufficient load on the cpu before triggering scale up and turning on the second core. This is where the 90% comes in, after that if there really is enough load to scale up more the load percentage is 50% because lets face it if the second core is on it might as well scale up a little more aggressively to allow more processing time to complete the task. But as you will see, the second the the load is released from the core the race to idle is near instantaneous as I can watch my clock cycles drop all the way down to 96mhz in less than a second after loading a resource hungry app. Sorry for the book... but like I said: thorough
What you know 'bout wearing a wolf on ya noggin?
