Governors #
CPU governors control exactly how the CPU scales between your "max" and "min" set frequencies. Most kernels have "ondemand" and "performance". The availability
- brazilianwax - Similar to smartassv2 with more aggressive ramping, so more performance, less battery.
- 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.
- intellidemand - Based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery (browsing mode).
- 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.
- interactivex - This is an Interactive governor with a wake profile. More battery friendly than interactive.
- lazy - Basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. Try to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
- lagfree - Similar to ondemand, but the main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. If there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current.
- lionheart - Lionheart is a conservative-based governor. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
- lionheartx - Based on Lionheart, but has a few changes on the tunables and features a suspend profile based on smartass governor.
- luzactive - Based on interactive and smartass. On the old version when workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency. For the new version, three more user configurable parameters: inc_cpu_load,pump_up_step, pump_down_step. Can set the threshold at which governor decides to scale up/down and the number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less thaninc_cpu_load, governor scales CPU down pump_down_step steps down. Example:
inc_cpu_load=70 pump_up_step=2 pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800. If current frequency=1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
- 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.
- ondemandx - An ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions.
- 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.
- savagedzen - Based on smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
- 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.
- smartassv2 - The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike smartass), so the entire frequency range is available for the governor to use during screen-on and screen-off state. This governor is a balance between performance and battery.
- userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
Notes:
- Stay away from using 100mhz during screen-off or screen-on states for three reasons:
- It seems 100 mhz uses more power than 200 mhz. According to tests, 100 mhz accounted to 1 W / GHz and 200 mhz to 0.7 W / GHz, when both the cores were online.
- 200 mhz can finish same task faster compared 100 mhz and thus hit deep idle soon.
- 200 mhz is the 'sweet spot' of frequency in SGS II. ie, the frequency used in the calculations based on the optimal energy to run (Eg: In Milestone it's 550 MHz). So , 'energetically efficient' frequency for our CPU is 200 mhz.
- Best way to improve battery life is to limit scaling max freq to 800 or 1000 mhz. Sgs2 can do majority of the task with 1000 or 800 as the max. OCing to 1600mhz draws considerably more power than stock 1200mhz or even 1400mhz. Try scaling between 200 and 1000 mhz for a day and feel the difference.
No comments:
Post a Comment
I would be glad to know if this post helped you.