一半君的总结纸

听话只听一半君

[REF][GUIDE]Most up to date guide on CPU governors and I/O schedulers by gsstudios

备忘录:Most up to date guide on CPU governors and I/O schedulers by gsstudios
What is a CPU governor?

A CPU governor in Android controls how the CPU raises and lowers its frequency in response to the demands the user is placing on their device. Governors are especially important in smartphones and tablets because they have a large impact on the apparent fluidity of the interface and the battery life of the device over a charge.

NOTE: You cannot change your CPU governor unless your phone is rooted and you have a ROM or app that lets you make a change. Also, different kernels (the intermediary software between your phone’s hardware and the operating system) offer different sets of governors.

Available CPU governors:

  1. OnDemand
  2. OnDemandX
  3. Performance
  4. Powersave
  5. Conservative
  6. Userspace
  7. Min Max
  8. Interactive
  9. InteractiveX
  10. Smartass
  11. SmartassV2
  12. Scary
  13. Lagfree
  14. Smoothass
  15. Brazilianwax
  16. SavageZen
  17. Lazy
  18. Lionheart
  19. LionheartX
  20. Intellidemand
  21. Hotplug
  22. Badass
  23. Wheatley
  24. Lulzactive
  25. PegasusQ\PegasusD
  26. HotplugX
  27. Abyssplug
  28. MSM DCVS
  29. Intelliactive
  30. Adaptive
  31. Nightmare
  32. ZZmove
  33. Sleepy
  34. Hyper
  35. SmartassH3
  36. SLP
  37. NeoX
  38. ZZmanX
  39. OndemandPlus
  40. DynInteractive
  41. Smartmax
  42. Ktoonservative\KtoonservativeQ
  43. Performance may cry (PMC)
  44. Dance Dance
  45. AbyssPlugv2
  46. IntelliMM
  47. InteractivePro
  48. Slim
  49. Ondemand EPS
  50. Smartmax EPS
  51. Uberdemand
  52. Yankactive
  53. Impulse
  54. Bacon
  55. Optimax
  56. Preservative
  57. Touchdemand
  58. ElementalX
  59. Bioshock
  60. Blu_active
  61. Umbrella_core
  62. ConservativeX
  63. Hyrdxq
  64. DevilQ
  65. Yankasusq
  66. Darkness
  67. Alucard
  68. Hellsactive
  69. Ragingmolasses
  70. Virtuous
  71. Sakuractive
  72. InteractiveX v2
  73. Alessa
  74. GallimaufryX
  75. AggressiveX
  76. Tripndroid
  77. Wrexy
  78. Xperience
  79. Stockdemand
  80. Zeneractive
  81. InteractiveB
  82. Aggressive
  83. IntellidemandV2
  84. Boostactive

Things to look out for in a CPU governor:

There are many CPU governors available on android, but there are some important things people should look out for before selecting their new governor:

– Speed – The more the better!!!! Usually having lots of speed equates to lower battery life, so it is best to balance this out.
– Battery life – More of this means more battery life!!! Being very battery friendly usually means less speed (or sometimes smoothness), so it’s best to balance this out.
– Stability – Some governors are plain unstable and some are rock solid. Of course people would want a stable CPU governor!!!
– Smoothness (or Fluidity) – This is not the same as speed, a governor can be fast but it doesn’t mean it is smooth. A way to test this is to scroll down/up pages or open and close apps. Of course, more smoothness = awesome phone experience

Descriptions:

1: OnDemand:

Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold (say 80 percent), the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google’s Interactive governor.

The problem with Ondemand is that once the task that triggered the clockspeed ramp is finished,the governor will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand’s ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life. The interactive governor was made to fix this problem as well a few others.

2: OndemandX:

Basically 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. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors.

3: Performance:

This locks the phone’s CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU’s C-states (low power states).

4: Powersave:

The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.

5: Conservative:

This governor biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.

The Conservative Governor is also frequently described as a “slow OnDemand,” if that helps to give you a more complete picture of its functionality. This is now a very inefficient governor and drains more battery than most modern governors.

6: Userspace:

This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU’s operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.

7: Min Max

Min Max is a governor that makes use of only min & maximum frequency based on workload… no intermediate frequencies are used!

8: Interactive:

Google’s own take on a CPU governor. Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive. It is significantly more responsive than OnDemand, because it’s faster at scaling to maximum frequency. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.

Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.

Interactive is the default governor of choice for today’s smartphone and tablet manufacturers.

9: InteractiveX:

Created by kernel developer “Imoseyon,” the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor’s defining feature, however, is that it locks the CPU frequency to the user’s lowest defined speed when the screen is off.

10: Smartass

Based on interactive, performance is on par with the “old” minmax and smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 it will cap it to your min frequency).

This governor will slowly ramp down frequency when the screen is off and it could also let the frequency go to low making your phone unusable (if min frequency is not checked).

11: SmartassV2:

Version 2 of the original smartass governor from Erasmux. 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 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. The motto of this governor is a balance between performance and battery. The problem with SmartassV2 is that it doesn’t behave properly on most multi-core devices but behaves normally on single-core devices. That’s why not many kernel developers include this governor on their kernel.

12: Scary

A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it’s above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to whatever the kernel developer sets it too and will still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.

13: Lagfree:

Lagfree is similar to ondemand. 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. Remember that 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. Some users report that video playback using lagfree stutters a little.

14: Smoothass:

The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL

15: Brazilianwax:

Similar to smartassV2. More aggressive ramping, so more performance, less battery

16: SavagedZen:

Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.

17: Lazy:

This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is 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.

18: Lionheart:

Lionheart is a conservative-based governor which is based on samsung’s update3 source.
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.

19: LionheartX

LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.

20: Intellidemand:

Intellidemand aka Intelligent Ondemand from Faux is yet another governor that’s based on ondemand. The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) 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. This is called browsing mode.

To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.

21: Hotplug:

The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel’s frequency table as the governor measures the user’s CPU load. However, the Hotplug governor’s defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as “hotplugging.”

22: BadAss:

Badass removes all of this “fast peaking” to the max frequency. To trigger a frequency increase, the system must run a bit with high load, then the frequency is bumped. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.

23: Wheatley:

Building on the classic ‘ondemand’ governor is implemented Wheatley governor. The governor has two additional parameters. Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly. So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.

Wheatley is a more performance orientated governor as it scales more aggressively than ondemand and sticks with higher frequencies.

24:Lulzactive\LulzactiveQ:

It’s based on Interactive & Smartass governors.

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.

New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set 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 than inc_cpu_load, governor scales CPU down pump_down_step steps down.

25: Pegasusq/Pegasusd

The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging. It is quite stable and has the same battery life as ondemand). Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called “Run Queue” queue that is ongoing, with their priority values ​​arranged (priority will be used by the task scheduler, which then decides which process to run next).

To ensure that each process has its fair share of resources, each will run for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.

26: Hotplugx

It’s a modified version of Hotplug and optimized for the suspension in off-screen

27: AbyssPlug

It’s a Governor derived from hotplug, it works the same way, but with the changes in savings for more battery life.

28: MSM DCVS

A very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements. It makes the phone’s CPU smoothly scale from low power, from low leakage mode to blazingly fast performance.Only to be used by Qualcomm CPUs.

MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS

29: IntelliActive

Based off Google’s Interactive governor with the following enhancements:

1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths. Therefore, it avoids CPU hotplugging.

This is a more performance oriented CPU governor that still has great battery life like the original Interactive.

30: Adaptive

This driver adds a dynamic cpufreq policy governor designed for latency-sensitive workloads and also for demanding performance.

This governor attempts to reduce the latency of clock so that the system is more responsive to interactive workloads in lowest steady-state but to reduce power consumption in middle operation level, level up will be done in step by step to prohibit system from going to
max operation level.

31:Nightmare

A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.

32: ZZmove

The ZZmove Governor by ZaneZam is optimized for low power consumption when the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. ZZmoove is not a good gaming governor as it aims to save battery, but it can be tuned to simulate other governors such as performance. This governor is still a WIP as the developer is constantly giving updates! Here are the available profiles:

Quote:

1) for Default (set governor defaults)
2) for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
3) for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
4) for ZaneZam Battery -> old untouched setting (a more ‘harsh’ setting strictly focused on battery saving DEV-NOTE: might give some lags!)
5) for ZaneZam Battery Plus -> NEW! reworked ‘faster’ battery setting (DEV-NOTE: recommended too! )
6) for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
7) for ZaneZam Moderate -> NEW! setting based on ‘zzopt’ which has mainly (but not strictly only!) 2 cores online
8) for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
9) for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
10) for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)

33: Sleepy

The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on Ondemand. It includes some tweaks like the Down_sampling variable and other features that set by the user through the sysfs of “echo” call. Sleepy is quite similar to Ondemandx.

34: Hyper

The Hyper (formerly known as kenobi) is an aggressive smart and smooth governor based on the Ondemand and is equipped with several features of Ondemandx suspend profiles. It also has the fast_start deep_sleep variable and detection features. In addition, the maximum frequency is in suspend mode 500Mhz or whatever the kernel developer sets it to. This is a more smoothness oriented governor which means that it is good for performance, without sacrificing much battery life.

35: SmartassH3

The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that’s the one thing people keep asking for more of. Based on SmartassV2.

36: SLP

It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.

37: NeoX

An optimized version of the pegasusq governor but with some extra tweaks for better performance. This means slightly more battery drainage than the original PegasusQ but it is still a balanced governor.

38. ZZmanx

ZZmanx is exactly the same as ZZmoove, but it has been renamed because DorimanX made it into his own version (possibly better performance) . However, it still suffers from below average gaming performance. (Refer to ZZmoove description for guide on profiles)

39. OnDemandPlus

Ondemandplus is an ondemand and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely. Reports have found that users find ondemandplus as a more battery friendly governor. In ondemandplus, the downscaling behavior from ondemand is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately.

40. DynInteractive

A dynamic interactive Governor. Similar to interactive in almost every way possible except it “dynamically” adapts its own tunables and settings depending on system load.

41. Smartmax

This is a new governor which is a mix between ondemand and smartassv2. By default this is configured for battery saving,so this is NOT a gamer governor! This is still WIP!

42. Ktoonservative\KtoonservativeQ

A combination of ondemand and conservative. Ktoonservative contains a hotplugging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior.

43. Performance may cry (PMC)

A governor based on Smartmax except it’s heavily tweaked for better and maximum battery life. This is not a gaming governor!

44. Dance Dance

Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it’s above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.

45. AbyssPlugv2

AbyssPlugv2 is a rewrite of the original CPU governor. It also fixes the problem where the governor is set only for the first core, but now governs all cores right from whatever utility you use. There have been comments on the lack of stability with this governor.

46. IntelliMM

A rewrite of the old Min Max governor and has 3 cpu states: Idle, UI and Max. Intelliminmax (intellimm) governor is designed to work with the newer SOCs with fixed voltage rails (ie MSM8974+ SOCs). It is designed to work within those fixed voltage ranges in order to maximize battery performance while creating a smooth UI operations. It is battery friendly and spends most of the time at lower frequencies.

47. Interactive Pro

A newer (modified) version of interactive which is optimized for devices such as the One Plus One. It is a more efficient than the original Interactive because it continuously re-evaluates the load of each CPU therefore allowing the CPU to scale efficiently.

48. Slim

A new governor from the cm branch and the slimrom project. This is a performance optimized governor and has been tuned a lot for newer devices such as the One Plus One.

49. Ondemand EPS

A modified version of Ondemand and is optimized for newer devices. It is based on the Semaphore Kernel’s Ondemand which is more optimized for battery life. The EPS at the end stands for Extreme power savings so this governor is biased to power savings!

50. Smartmax EPS

This governor is based on Smartmax but is optimized for ‘Extreme Power Saving’ (hence the EPS suffix). This means it uses less battery than the original Smartmax so it is not a very good gaming governor (again!) This is only found on newer devices.

51. Uberdemand

Uberdemand is Ondemand with 2-phase feature meaning it has a soft cap at 1728 MHz so your cpu won’t always go directly to max, made by Chet Kener.

52. Yankactive

A slightly modified interactive based governor by Yank555.lu. It has battery tweaks added onto it so expect better battery life! Based on user reports, this governor behaves more battery friendly than the original interactive governor without sacrificing performance.

53. Impulse

An improved version of interactive modified by neobuddy89. Impulse aims to have a balance between battery and performance just like interactive but has some tweaks to save battery.

54. Bacon

This is nothing but polished interactive governor branded as “bacon” since it was adapted from bacon device thanks to neobuddy89. Most of the tweaks are for performance/latency improvements

55. Optimax governor

This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC’s governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative.
It originates from Cl3kener’s Uber kernel for Nexus 5, where it has quite a reputation for battery life

56. Preservative governor

This is based on the idea that the CPU will consume a lot of power when it changes frequency. It is based on the conservative governor. The idea is that it will stay at the step specified (702MHz selected by the creator Bedalus) unless needed. You will notice it will hover around 702 a lot, and not go above too much, and only to min freq when NOTHING is happening at all. This is most beneficial when you are doing something like reading; the screen is static or playing light games that won’t need boosting any more
The governor comes from Moob kernel for nexus 4

57. Touchdemand

Touchdemand is based on the ondemand cpu governor but has been modified for the Tegra 3 chip (tablet only) and has additional tweaks for touchscreen responsiveness.

58. ElementalX

If you are an owner of a nexus device, you probably have heard of a governor named ElementalX. Named after the kernel, elementalX is based on interactive but with some additional performance tweaks. This governor focuses on performance and not battery
savings!

59. Bioshock

Not the game, but rather the CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart. Good balance between battery savings and performance.

60. Blu_active

A new cpu governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.

61. Umbrella_core

A new cpu governor by twisedumbrella based on interactive that is focused on battery life and not performance. It will still ramp up to a set frequency but will not stay at high frequencies for long. This governor tends to stay in high-mid range frequencies during screen_off.

62. ConservativeX

Also developed by Imoseyon (feat. briefly in the Lean Kernel for Galaxy Nexus), the ConservativeX governor behaves like the Conservative governor with the added benefit of locking the CPU frequency to the lowest interval when the screen is off. This governor may additionally perform hotplugging on CPU1, but there is no documentation to confirm that suspicion at this time.

63. HydrxQ

Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak). This means more performance and less battery life.

64. DevilQ

An aggressive pegasusq governor which keeps the hotplugging at max 2 cpu cores to offline). This is pretty much a more optimized pegasusq for phone’s with quad core processors.

65. YankasusQ

Yankasusq is another modified pegasusq but with including screen off freq tunable and some other modifications as well. The difference between PegasusQ and YanksusQ is that it doesn’t ramp too aggressively when screen turns on (less battery drainage).

66. Darkness

It’s based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests

67. Alucard

A favourite choice and one of the original governors that Alucard_24 made. Alucard is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.

68. Hellsactive

A heavily modified intelliactive governor by @hellsgod that has been tweaked to improve battery life. Hellsactive is less aggressive compared to intelliactive so the battery life will be more like the original interactive.

69. Ragingmolasses

Besides a gov with an awesome name its a mash up of conservative and ondemand and scales based on load with few tunables. Its meant to be simple, fast, and efficient at keeping the frequency away from the max clock unless it is absolutely needed. it includes gboost for better gaming.

70. Virtuous

It sets your max cpu for wake and sleep and changes the governor when your device is awake or asleep. It saves battery by lowering cpu frequencies while the device sleeps, when it awakes it automatically speeds it up again. Or alternately you can set the cpu.It is based on smartassV2(It uses 2 governors, one for sleep and other for awake)

71. Sakuractive

An aggressive hybrid of ondemand and hotplug, which means it will scale like ondemand, except a little more aggressive. But also acts like hotplug as it shuts down multiple CPU cores to save power.

72. InteractiveX V2

Also developed by Imoseyon (feat. in the Lean Kernel for Galaxy Nexus), the InteractiveX V2 governor behaves like InteractiveX, and additionally forces CPU1 into a hotplug state when the screen is off.

73. Alessa

A less aggressive and more stable ondemand modified by TeamMex. A good compromise between performance and battery. It can be used with the complementary hotplug governor. Please note that this governor is still a WIP!

74. GallimaufryX

A modded ondemand that is a 2-stage ondemand governor with speed tweaks. It includes imoseyon’s screen-off hotplugging code.

75. AggressiveX

A modded conservative governor but with lots of tweaks to increase snappiness while saving power. It also includes imoseyon’s screen-off hotplugging code.

76. Tripndroid

Instead of the I/O scheduler, this is a CPU governor based on ondemand with extra tweaks for performance

77. Wrexy

Wrexy is a conservative based governor. Its similiar to the Lionheart gov. It tends to stay out of higher frequencies to favor lower frequencies but performance is not much affected.

78. Xperience

A tweaked smartassv2 for better performance. Created by TeamMex.

79. Stockdemand

A heavily modified ondemand for better performance and battery life. It is still a well balanced governor and it is designed for everyday use.

80. Zeneractive

This new “zeneractive” governor is based on interactive. It handles frequency scaling the exact same as interactive and has the same tunables as interactive for frequency scaling. However, on zeneractive all of the new hotplugging code that’s in there is “from scratch.”

81. InteractiveB

An interactive based governor with a more balance battery life/performance profile

82. Aggressive

Like Lionheart, it is based on conservative, but even more aggressive

83. Intellidemandv2

Much like its predecessor, intellidemandv2 is an intelligent ondemand with browsing detection and scales based on GPU loading. It has been optimized for specific devices and has better battery life and performance.

84. Boostactive

Based on Interactive but with cpu frequency boosting capabilities. This is performance oriented governor.

Hotplugging drivers:
mpdecision: Qualcomm’s default hotplugging driver

msm_hotplug: great battery life, a custom qualcomm based hotplugging driver by myflux

intelliplug: Great for performance, more customization options by faux

Alucard: A great hotplugging driver by Alucard

Custom kernels may have their own hotplugging drivers but they are usually based on these ones.

I recommend playing with the Hotplugging drivers. Alucard Hotplug seems to be the best for battery life whereas the default hotplug for qualcomm devices are better for performance. If you experience problems, keep the setting on AUTO. If you want to experiment, be sure to expect better/worse battery life!

GPU governors

Simple: It’s a new governor for the gpu frequency scaling. It will allow a more fine grained control over how the gpu scales up and down then the previous ones. This means either more performance or more battery savings

Ondemand: Much like the CPU governor, Ondemand will ramp up the frequency when a load is detected. A good balance between performance and battery savings.

MSM-Adreno: The default GPU governor used by qualcomm for their adreno GPUs. It is more performance orientated than ondemand therefore it gives better performance in games but less battery life.

Performance: As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don’t care about your battery life.

Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.

Categorization:

There are four different categories CPU governors can exist as.

1) Ondemand Based:
Works on “ramp-up on high load” principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree, PegasusQ, HYPER, Wheatley, Hotplug, HotplugX, AbyssPlug, AbyssPlugv2, Nightmare, Sleepy.

2) Conservative Based:
Works by biasing the phone to prefer the lowest possible clockspeed as often as possible. Members: Conservative, Lionheart, LionheartX

3) Interactive Based:
Works on “make scaling decision when CPU comes out of idle-loop” principle. Members: Interactive, InteractiveX, Intelliactive, Lulzactive, Luzactiveq, Smartass, SmartassV2, SmartassH3, Brazilianwax, SavagedZen, Dyninteractive, Interactive Pro

4) Unique Category:
These do not fall into any other category above and/or possess unique attributes. Members: Userspace, Powersave, Performance, Min Max, ZZmove, MSM DCVS, IntelliMM

5) Hybrid Category:
These have a mix of two (or more) CPU governor behaviors. Members: Smartmax, Dancedance, Performance May Cry(PMC), Ktoonservative, KtoonservativeQ

Here are some CPU Governors I recommend…

Rating system:
Best – This CPU governor is simply the best (for the category), highly recommended.
Great – This CPU governor is very good, will suit most people.
Good – This CPU governor is good, but might not suit everyone.
Requires tuning – This CPU governor requires tuning, not for beginners.

If your kernel (not the rom) doesn’t have the CPU governors that has been marked as ‘best’, use the ones that have been marked as ‘great’.

Also, if there is more than one governor marked as ‘best’, choose the one that is available for you. If all are available, choose any.

For performance:

Single-core:
– Performance – Good
– Interactive/InteractiveX – Best
– SmartassV2 – Great

Multi-core:
– Performance – Good
– Interactive/InteractiveX – Great
– ZZMoove/ZZmanX – Requires tuning, use performance profile
– HYPER – Great
– Lionheart/LionheartX – Best
– Intelliactive – Great
– LulzactiveQ – Great
– PegasusQ – Good

For battery life:

Single-core:
– Powersave – Good
– Ondemand – Best
– Conservative – Good

Multi-core:
– SLP/Sleepy – Great
– Perfomance may cry (PMC) – Best
– Ondemand – Best
– Powersave – Good
– Smartmax – Best
– ZZMoove/ZZmanX – Requires tuning, use battery plus or battery profile
– Conservative – Good

For balanced battery saving and performance:

Single-core:
– Interactive/Intelliactive – Best
– Ondemand/OndemandX – Stock, Best
– SmartassV2 – Great

Multi-core:
– LulzactiveQ – Good
– Intelliactive – Good
– Interactive/InteractiveX – Great
– Yankactive/YanksusQ – Best
– Ondemand/OndemandX – Stock, Best
– PegasusQ – Good
– HYPER – Best
– Intellidemand – Good
– ZZMoove/ZZmanX – Requires tuning, use optimized or default profile
– Ktoonservative – Great

For gaming:

Single-core:
– Interactive/InteractiveX – Best
– Performance – Great
– Ondemand/OndemandX – Great
– SmartassV2 – Great

Multi-core:
– Lionheart/LionheartX – Best
– Intelliactive – Great
– Yankactive – Good
– Wheatley – Good
– Interactive/InteractiveX – Best
– PegasusQ – Good
– Ondemand/OndemandX – Great
– HYPER – Best
– LulzactiveQ – Best
– Ktoonservative – Great
– ZZMoove/ZZmanX – Requires tuning, use gaming or performance profile

Other CPU Governors not mentioned in the recommended section are either not used by people anymore or they are not suited for most people or have been removed from kernels.

What if my kernel allows my phone to run multiple governors?
Depending on how you would want to configure your phone’s CPU, usually having the same governor for all CPUs is the way to go. This is because this will minimize any issues from occurring when the kernel is switching between governors and also this allows the phone to behave as it should stated in the CPU governor descriptions. If you want to have multiple CPU governor arrangements, here are some examples of arrangements that can be set:

Note: The following guide assumes your phone has 4 cpu cores. Not all phones and kernels support the feature to change individual governors!

Stock configuration
All CPUs running with ondemand/interactive/conservative based governor

Performance based, with slight battery saving features
CPU0+CPU1 performance based governor, CPU2+CPU3 ondemand based OR CPU0+CPU1+CPU2 performance based, CPU3 ondemand/conservative based

Ondemand with extra performance and with battery saving features (Recommended for extra performance)
CPU0 performance based governor, CPU1+CPU2+CPU3 ondemand based

Pure performance
All CPUs running performance based governor

Conservative+Ondemand based
CPU0+CPU1 conservative based, CPU2+CPU3 ondemand based (or vise versa, doesn’t really matter)

Note: It is not recommended to use performance based governors on the last couple of CPU cores as you will find higher battery drainage!

Benchmark graphs:

Setup:
Phone: Samsung Galaxy S2 i9100
Governor: as per indicated
Hotplug: Default
I/O Scheduler: SIO
Kernel: DorimanX 10.44 v008
Frequency scaling: 200-1200mhz
App: Nofrills CPU
Test procedure: Opening stock browser, navigating home screens, navigating settings screen

Link to raw data: https://drive.google.com/file/d/0B3A…ew?usp=sharing

Here are more graphs (thanks to Haldi!)


Having trouble seeing the graph above? Here is the direct link to the image: http://i.imgur.com/PbtNyab.png

For more info about Haldi’s benchmarks, visit here: http://forum.xda-developers.com/show….php?t=2768979

Credits go to http://forum.xda-developers.com/show….php?t=1736168, http://forum.xda-developers.com/show….php?t=1663809 and many others for their descriptions.

I/O Schedulers 


S/W or App’s for using these features: 
1. SetCPU (Paid)
2. No-frills CPU. (Free)
3. Inbuilt Performance Settings (Only in custom roms, Free)
4. Trickster Mod Kernel Settings (Free)
5. Compatible kernel managers (e.g Stweaks, Synapse, etc.)

This post includes:

– I/O scheduler descriptions
– Recommendations
– Comparisons
– Graphs

Why change your phones I/O Scheduler?

Most phone manufacturers keep your phones I/O Schedulers locked so users are unable to modify any values which could change the performance of your phone. However, once your phone is rooted, you can change these values allowing the potential to boost your phones performance and even slightly increase battery life. Here is a thorough guide on all of the common i/o schedulers.
What is an I/O Scheduler:

Input/output (I/O) scheduling is a term used to describe the method computer operating systems decide the order that block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called ‘disk scheduling’.

I/O schedulers can have many purposes depending on the goal of the I/O scheduler, some common goals are:

– To minimise time wasted by hard disk seeks.
– To prioritise a certain processes’ I/O requests.
– To give a share of the disk bandwidth to each running process.
– To guarantee that certain requests will be issued before a particular deadline.

Which schedulers are available? 

  1. CFQ
  2. Deadline
  3. VR
  4. Noop
  5. Anticipatory
  6. BFQ
  7. FIOPS
  8. SIO (Simple)
  9. Row
  10. ZEN
  11. Sioplus
  12. FIFO
  13. Tripndroid
  14. Test



Things to look out for in an I/O scheduler:

There are many I/O schedulers available on android, but there are some important things people should look out for before selecting their new scheduler:

– Speed – The more the better!!!! Usually having lots of speed equates to lower battery life, so it is best to balance this out.
– Battery life – More of this means more battery life!!! Being very battery friendly usually means less speed (or sometimes smoothness), so it’s best to balance this out. 
– Stability – Some schedulers are plain unstable and some are rock solid. Of course people would want a stable I/O scheduler!!!
– Multitasking capabilities – An important factor to I/O schedulers. Some schedulers can handle lots of apps, some can’t. Usually being more multitasking capable equates to higher i/o latency, so it is best to balance this out. 
– Smoothness (or Fluidity) – This is not the same as speed, a scheduler can be fast but it doesn’t mean it is smooth. A way to test this is to scroll down/up pages or open and close apps. Of course, more smoothness = awesome phone experience


Descriptions:


Anticipatory:
Anticipatory scheduling is an algorithm for scheduling hard disk input/output. It seeks to increase the efficiency of disk utilization by “anticipating” synchronous read operations. It is very rare to see this scheduler on mobile phones.

Benefits:
– Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like noop.

Disadvantages:
– Requests from process operations are not always available
– Reduced write performance on high-performance hard drives
– Not very common in most kernels (or even phones these days)

CFQ:
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. A time slice allocated for each queue depends on the priority of the ‘parent’ process. V2 of CFQ has some fixes which solves process’ i/o starvation and some small backward seeks in the hope of improving responsiveness.

Benefits:
– Has a well balanced I / O performance
– Excellent on multiprocessor systems 
– Regarded as a stable I/O scheduler
– Good for multitasking

Disadvantages: 
– Can make your phone lag when multitasking between intensive applications
– Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
– Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks


Deadline:
The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

Benefits:
– It is nearly a real-time scheduler. 
– Excels in reducing latency of any given single I/O 
– Best scheduler for database access and queries. 
– Does quite well in benchmarks
– Like noop, it is a good scheduler for solid state/flash drives
– Good for light and medium multitasking workloads

Disadvantages:
– If the phone is overloaded, crashing or unexpected closure of processes can occur

ROW:
The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices, we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have as much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly. The main idea of the ROW scheduling policy is: If there are READ requests in pipe – dispatch them but don’t starve the WRITE requests too much. 

Benefits:
– Faster UI navigation and better overall phone experience
– Faster boot times and app launch times
– Possibly better battery life

Disadvantages:
– Slower write speeds
– Not great for heavy multitasking
– Not a scheduler for benchmarking
– Some intensive applications like games could slow down your phone

SIO (Simple):
Simple I/O scheduler (SIO) aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Benefits:
– It is simple and stable.
– Reliable I/O scheduler
– Minimized starvation for inquiries
– Good battery life
– Good for light and medium multitasking workloads

Disadvantages:
– Slow random write speeds on flash drives as opposed to other schedulers.
– Sequential read speeds on flash drives are not as good as other IO schedulers

Noop:
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Benefits:
– Serves I/O requests with least number of cpu cycles.
– Is suitable for flash drives because there is no search errors
– Good data throughput on db systems
– Does great in benchmarks

Disadvantages:
– Reducing the number of CPU cycles corresponds to a simultaneous decline in performance 
– Not the most responsive I/O scheduler
– Not very good at multitasking (especially heavy workloads)

VR:
Unlike other scheduling software, synchronous and asynchronous requests are not handled separately, but it will impose a fair and balanced within this deadline requests, that the next request to be served is a function of distance from the last request.

Benefits:
– Generally excels in random writes.

Disadvantages:
– Performance variability can lead to different results (Only performs well sometimes)
– Very often unstable and unreliable

BFQ:
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it’s budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it’s behavior. 

Benefits:
– Has a very good USB data transfer rate.
– The best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
– Regarded as a very precise working Scheduler
– Delivers 30% more throughput than CFQ
– Being constantly updated
– Good for multitasking, more responsive than CFQ

Disadvantages:
– Not the best scheduler for benchmarks 
– Higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
– Slower UI navigation

ZEN:
ZEN scheduler is based on the VR Scheduler. It’s an FCFS (First come, first serve) based algorithm, but it’s not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it’s pretty much the same as no-op blended with VR features.

Benefits:
– Well rounded IO Scheduler
– Very efficient IO Scheduler
– More stable than VR, more polished
– Quite battery friendly
– Great for light and medium multitasking workloads

Disadvantages:
– Not found in all kernels

Sioplus:
Based on the original SIO scheduler with improvements. Functionality for specifying the starvation of async reads against sync reads; starved write requests counter only counts when there actually are write requests in the queue; fixed a bug). 

Benefits:
– Better read and write speeds than previous SIO scheduler
– Good battery life

Disadvantages:
– Performance is not a great as SIO
– Fluctuations in performance may be observed
– Not very reliable compared to SIO
– Not found in all kernels

FIOPS: 
This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency.

Benefits:
– Achieves high read and write speeds in benchmarks, usually performs the best 
– Faster app launching time and overall UI experience
– Good battery life
– Low impact to system performance
– Good for light and medium multitasking workloads

Disadvantages:
– Not very common in most kernels
– Not the most responsive IO scheduler (Can make phone lag)
– Not good at heavy multitasking 

FIFO (First in First Out):
A relatively simple io schedulers that does what has been described. It is also known as FCFS (First come first serve) but this really isn’t true. It does basic sorting; sorting the processes according to the appropriate order and nothing else. In other words, it is quite similar to noop. 

Benefits:
– Serves I/O requests with least number of cpu cycles.
– Is suitable for flash drives because there is no search errors
– Good data throughput on db systems

Disadvantages:
– Reducing the number of CPU cycles corresponds to a simultaneous decline in performance 
– Not very good at multitasking

Tripndroid:
A new I/O scheduler based on noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR

Benefits:
– Great at IO performance and everyday multitasking
– Well rounded and efficient IO scheduler
– Very responsive I/O scheduler (Compared to FIOPS)
– Quite battery friendly 
– Great at light and medium multitasking workloads

Disadvantages:
– Not found in all kernels
– Performance varies between different devices (Some devices perform really well)

Test:
The test I/O scheduler is a duplicate of the noop scheduler with addition of test utility.It allows testing a block device by dispatching specific requests according to the test case and declare PASS/FAIL according to the requests completion error code.

Benefits:
– Same as noop

Disadvantages:
– Same as noop

Results :

Setup:
Phone: Sony Xperia Z2
Scheduler: as per indicated
Read Ahead: 512kB
App: AndroBench 4

Here is a graph of the performance of the i/o schedulers. Note: a higher score doesn’t mean it is the best io scheduler. These numbers mean nothing in real world performance, so take the following a mere glimpse of the performance of schedulers.

Sequential in MB/sec (Higher is better)



Random in IOPS (Higher is better)


Thanks haldi for the graphs! Link: http://forum.xda-developers.com/show…3&postcount=85

Recommended IO schedulers:

For everyday usage:
– SIO (My personal favourite)
– ZEN (Second choice)
– Tripndroid (Third choice)
– ROW (Forth choice)
– NOOP
– CFQ
– Deadline 


For battery life:
– NOOP (First choice)
– FIOPS (Second choice)
– SIO (Third choice)
– ROW (Forth choice)
– FIFO


For gaming: 
– SIO (First choice)
– Tripndroid (Second choice)
– ZEN (Third choice)
– Deadline 
– CFQ 
– ROW 


For performance(Benchmarking):
– FIOPS (First choice) 
– Tripndroid (Second Choice)
– Deadline (Third choice)
– NOOP
– SIO 


For heavy multitasking: 
– BFQ (First choice)
– CFQ (Second choice)
– Deadline (Third choice)


IO Scheduler Comparison

Overall performance:

Best<————————————————————————->Worst
FIOPS > Noop > ZEN > Tripndroid > SIOplus > SIO > ROW > > VR > Deadline > BFQ > CFQ

Multitasking performance:

Less Apps<————————————————————>Many Apps
Noop < FIFO < FIOPS < SIO < SIOplus < ROW < Tripndroid < ZEN < Deadline < VR < CFQ < BFQ

Battery life:

Best<————————————————————————-> Worst
Noop > FIFO > FIOPS > SIO > SIOplus > ROW > ZEN > Tripndroid > Deadline > VR > CFQ > BFQ


How did I come to this conclusion you may ask? With I/O schedulers, it’s best to have a low latency, low overhead and to allow access times to be as fast as possible. The most basic I/O schedulers like SIO, NOOP and FIOPS are great for flash devices. They are also great for mobile phones too as there aren’t much overheads, they have the least impact to performance in other words. Whereas schedulers including BFQ and CFQ have much more overheads because of the way they treat processes (queuing) and so they can cause your phone to slow down (affects performance). ROW is different from all of the schedulers as it prioritizes read requests over writes. This can be good when you only care about general UI responsiveness however you should expect slow speeds when coping files from your PC to phone or when you decide to install something. I/O schedulers like ZEN and Tripndroid are great all-rounders as they don’t do much sorting yet they still achieve pretty well in tests, but that doesn’t mean they are flawless. VR in the other hand is just a bit unstable for normal or heavy use and so it is hard to recommend it to people. 

In the end, the best i/o governor can not be easily be decided from anyone on the internet, therefore you will need to choose a scheduler that would satisfy your needs and one that you think works the best.


Source: xda-developers, andrux-and-me.blogspot.com.au

Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: