Android CPU Governor Reference, read it if you have time

Wheatley governor – in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice….

 

The known ones are really good described here one the setcpu page:

CPU Scaling Governors
CPU governors control exactly how the CPU scales between your “max” and “min” set frequencies. Most kernels have “ondemand” and “performance.” The availability :

ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn’t needed.
interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels. The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
userspace – A method for controlling the CPU speed that isn’t currently used by SetCPU. For best results, do not use the userspace governor.
smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.

the rest is nice described here:

lazy (http://forum.xda-developers.com/show….php?t=1276092) – is ondemand but with an added option to stay longer on a certain frequency. This is due to the fact that some CPU’s dont like too quick freq changes when sampling rate for decision making is set too low. See link for more.
lulzactive (http://tegrak2x.blogspot.com/2011/11…vernor-v2.html) – is basically interactive governor with added smartass bits and variable (as opposed to fixed amout) frequency scaling, based on currently occuring cpu loads. Has, like smartass, a sleep profile built-in. See link for details on exact scaling.
lagfree (http://forum.xda-developers.com/show….php?t=1272933) – seems to be ondemand but with a lessend tendency to ramp up to 100% but rather also use steps available in between 0-100%.
intellidemand (freely translated from http://www.android-hilfe.de/root-hac…-governor.html) – behaves like ondemand when the system is under heavy use, it behaves differently when the system is mostly ideling. That mode is colled “browsing mode” or “browser mode” or whatever. It seems to be some sort of “intelligent” demand sensing/analysing ondemand governor.
smartassV2 – this one should be known. It’s the same as smartass(V1) but tweaked. Same code author. I heard one should use smartassV2 instead of smartass when available.
ondemandx – is ondemand with an added sleep profile built-in. I believe all …X kernels are the default kernels but with an added sleep profile.

AbyssPlug Governor:

Abyssplug governor is a modified hotplug governor

Hotplug Governor:
The “hotplug” governor scales CPU frequency based on load, similar to
“ondemand”. It scales up to the highest frequency when “up_threshold”
is crossed and scales down one frequency at a time when “down_threshold”
is crossed. Unlike those governors, target frequencies are determined
by directly accessing the CPUfreq frequency table, instead of taking
some percentage of maximum available frequency.

The key difference in the “hotplug” governor is that it will disable
auxillary CPUs when the system is very idle, and enable them again once
the system becomes busy. This is achieved by averaging load over
multiple sampling periods; if CPUs were online or offlined based on a
single sampling period then thrashing will occur.

Sysfs entries exist for “hotplug_in_sampling_periods” and for
“hotplug_out_sampling_periods” which determine how many consecutive
periods get averaged to determine if auxillery CPUs should be onlined or
offlined. Defaults are 5 periods and 20 periods respectively.
Otherwise the standard sysfs entries you might find for “ondemand” and
“conservative” governors are there.

Facebook comments:

comments

Leave a Reply

Your email address will not be published.

Connect with Facebook