hello guys so i was looking at this project for Motorola Droid X:
http://code.google.com/p/milestone-overclock/
since Droid X has similar OMAP3630 chipset i thought we could try it out for this device...
if it has already been tried out by u guys then sorry for dupe post
anyways the sources available (milestone-overclock-module-1.4.8.tar.gz) were not directly compatible with the i9003 kernel sources (GB_CHN_UPDATE1) so i have modified it slightly.... and now the module gets compiled and it gets loaded (by insmod)... the sysfs and proc interface is active... even the app (MilestoneOverclock148.apk) detects the module correctly... but the changes dont work...
i invite all devs to help out with this...
modified sources are posted here:
https://github.com/DooMLoRD/i9003-overclock
noobs kindly dont spam this thread....
P.S.: Droid X has got overclock upto 1.4GHz with help of this so i am sure we can try little more overclock than 1.1GHz
If you look at the Samsung code in arch/arm/mach-omap2 and /plat-omap, and compare it with code seen for example in the nook color sources (OMAP 3630, see here), there are HUGE differences.
Normally the opp frequency table seems to be hard coded and easy to edit. Samsung on the other hand decided to dynamically assemble it in board-latona.c with info from cpufreq34xx.c (if I overlook that correctly). These differences could be the reason the module does not work.
Further, the line Amit and you changed in clock.c could - but I am not quite sure - actually lead to 10% higher clocks on every opp step. Because what you changed
Code:
- mpurate *= 1000000;
+ mpurate *= 1100000;
is a conversion factor from MHz to Hz. The line
Code:
if (mpurate < 1000)
above seems to be a logical check if the desired clock has been given in Hz or MHz, which is expected to be at max 800 for the 3630. For our 3640 the highest frequency is 1000, which would require the check to be
Code:
if (mpurate < 1001)
or similar, but they might have overlooked this change. If the input is below this boundary, it is thought to be in MHz, and is converted to match the internal logic which works with Hz only.
And two more questions: I experimented a lot with the OC code, and even added two new opps (1100/840 and 1200/865) to my tables. I could select them, and everything including cpufreq scaling tables was correct, but the CPU never was actually clocked above 1000MHz. Do you know why? And did you check if it is with your kernel (compare benchmark values, do not trust any other source, they all lie )?
previously i was also having milestone A853 and by the overclock module it can be overclocked to 1.2 ghz
XDA_Bam said:
If you look at the Samsung code in arch/arm/mach-omap2 and /plat-omap, and compare it with code seen for example in the nook color sources (OMAP 3630, see here), there are HUGE differences.
Normally the opp frequency table seems to be hard coded and easy to edit. Samsung on the other hand decided to dynamically assemble it in board-latona.c with info from cpufreq34xx.c (if I overlook that correctly). These differences could be the reason the module does not work.
Further, the line Amit and you changed in clock.c could - but I am not quite sure - actually lead to 10% higher clocks on every opp step. Because what you changed
Code:
- mpurate *= 1000000;
+ mpurate *= 1100000;
is a conversion factor from MHz to Hz. The line
Code:
if (mpurate < 1000)
above seems to be a logical check if the desired clock has been given in Hz or MHz, which is expected to be at max 800 for the 3630. For our 3640 the highest frequency is 1000, which would require the check to be
Code:
if (mpurate < 1001)
or similar, but they might have overlooked this change. If the input is below this boundary, it is thought to be in MHz, and is converted to match the internal logic which works with Hz only.
And two more questions: I experimented a lot with the OC code, and even added two new opps (1100/840 and 1200/865) to my tables. I could select them, and everything including cpufreq scaling tables was correct, but the CPU never was actually clocked above 1000MHz. Do you know why? And did you check if it is with your kernel (compare benchmark values, do not trust any other source, they all lie )?
Click to expand...
Click to collapse
Yes I know the changes in diff omap kernel sources... Spent a few hrs today comparing milestone/droid x and i9003 kernel sources to get this module complied and loading...
I am sure that the change done by amit is correct, because there is a very prominent change in linpack scores ~18 compared to ~16 which is typical of a 10% overclock...
As for ur other two questions I posted this earlier in the other thread
DooMLoRD said:
Not sure... These omap chips seem to have only 4 bins (300/600/800/1000)... We are currently making the 1000 MHz bin run at 1100mhz... I am not sure if we can add extra bins... I tried adding a lower 125MHz bin, it was shown by setcpu but the device never really went below 300mhz... May be we need to investigate it further...
Sent from my R800i using XDA App
Click to expand...
Click to collapse
P.S.: the chip on this phone is OMAP3630
Sent from my R800i using XDA App
DooMLoRD said:
I am sure that the change done by amit is correct, because there is a very prominent change in linpack scores ~18 compared to ~16 which is typical of a 10% overclock...
Click to expand...
Click to collapse
OK, so the overclock is working. Nice Concerning the mpurate, have a look here. The author is working at TI, so I expect him to be familiar with the code. However, that does not mean we can't use the conversion factor for overclock. It's just not "clean".
DooMLoRD said:
P.S.: the chip on this phone is OMAP3630
Click to expand...
Click to collapse
Yep, you're right. Got that wrong
---------- Post added at 10:50 PM ---------- Previous post was at 10:41 PM ----------
And another idea: For the Nook Color, there is a guy who implemented an interface and an app to change the clocks. It is different from droid-overclock, because he implemented a sysfs interface in the kernel sources. Hope this helps.
http://code.google.com/p/milestone-overclock/
sorry its of no use as yr already checked it out
XDA_Bam said:
And another idea: For the Nook Color, there is a guy who implemented an interface and an app to change the clocks. It is different from droid-overclock, because he implemented a sysfs interface in the kernel sources. Hope this helps.
Click to expand...
Click to collapse
That looks very much like the sysfs interface we added for VDD control on QSD8250/MSM7X30... Should work I think...
Sent from my R800i using XDA App
akashsgpgi said:
http://code.google.com/p/milestone-overclock/
sorry its of no use as yr already checked it out
Click to expand...
Click to collapse
U should be BANNED for spamming.... The link u posted is already there in the second line of the main post...
READ!!!!
Sent from my R800i using XDA App
I made progress with the sysfs interface seen on the Nook. Kernel boots, and the correct rates are displayed under /sys/power/mpu_freq_oppX. I was also able to set the hightest opp to 800 MHz, so that the two highest were both at the same frequency. The setting worked (confirmed with Linpack). But 1100 MHz was ignored (stayed at 1000). Looking into this further.
XDA_Bam said:
I made progress with the sysfs interface seen on the Nook. Kernel boots, and the correct rates are displayed under /sys/power/mpu_freq_oppX. I was also able to set the hightest opp to 800 MHz, so that the two highest were both at the same frequency. The setting worked (confirmed with Linpack). But 1100 MHz was ignored (stayed at 1000). Looking into this further.
Click to expand...
Click to collapse
so wht cpu freq table are u using exactly?
wht i think is we should concentrate on this (atleast for now):
just keep the 4 bins as is (300, 600, 800, 1000)
then try n get the access to these via sysfs (or proc)
see if we can modify them via that interface, say change 1000 to 1100 or change 800 to 900
and then do tests if these work...
if possible make a sysfs (or proc) interface for VDD (voltage control) too...
have u pushed the testing changes... i am working on same thing here... might help to speed things up...
I am currently testing on the master branch, so the branch is "wrong", but this is the commit:
Sysfs interface
Because only underclock works as of now, I am tested setting
Code:
if (mpurate < 2000)
but that didn't help. Now I will define 1100 and 1200 MHz steps in board-latona.c and cpufreq34xx.c to see if this helps.
EDIT: Nope, that didn't solve it. CPU does not run at 1100. Not even 900. Stays at 1000 in both cases. 800 can be forced...
some updates on the overclock module:
we need to search in /proc/kallsyms for:
clk_init_cpufreq_table
cpufreq_stats_update
on our kernel (uc-kernel v04) they are at:
Code:
c005a198 T clk_init_cpufreq_table
c03c5aec t cpufreq_stats_update
these may be different on stock kernel we need to use specific address
I just thought this might be helpful since Optimus black has the same hardware.
joelmonty said:
I just thought this might be helpful since Optimus black has the same hardware.
Click to expand...
Click to collapse
its the same module dude...
these are all based on milestone-overclock module
DooMLoRD said:
some updates on the overclock module:
we need to search in /proc/kallsyms for:
clk_init_cpufreq_table
cpufreq_stats_update
on our kernel (uc-kernel v04) they are at:
Code:
c005a198 T clk_init_cpufreq_table
c03c5aec t cpufreq_stats_update
these may be different on stock kernel we need to use specific address
Click to expand...
Click to collapse
Why these two? Cpufreq seems to be quite happy with the frequency tables. All frequencies are correctly listed, and the highest available for hardware and scaling are correct (say 1100, if I set it). But some "mysterious barrier" doesn't let the cpu clock as high as requested by cpufreq.
XDA_Bam said:
Why these two? Cpufreq seems to be quite happy with the frequency tables. All frequencies are correctly listed, and the highest available for hardware and scaling are correct (say 1100, if I set it). But some "mysterious barrier" doesn't let the cpu clock as high as requested by cpufreq.
Click to expand...
Click to collapse
read the sources of the module it explains why we need to look at those values...
DooMLoRD said:
read the sources of the module it explains why we need to look at those values...
Click to expand...
Click to collapse
Looked into it, and got the module to load and change frequencies by manually setting omap2_clk_init_cpufreq_table_addr=0xXXXXXX. I was able to underclock to 800 and back to 1000 MHz. 1200 was set, but not correctly applied - the mpu was still running at 1000 MHz. Further on, it ****ed up the frequency table. Instead of [300,600,800,1000] it was [600, 600, 1000, 1000] after the test. Not good
XDA_Bam said:
Looked into it, and got the module to load and change frequencies by manually setting omap2_clk_init_cpufreq_table_addr=0xXXXXXX. I was able to underclock to 800 and back to 1000 MHz. 1200 was set, but not correctly applied - the mpu was still running at 1000 MHz. Further on, it ****ed up the frequency table. Instead of [300,600,800,1000] it was [600, 600, 1000, 1000] after the test. Not good
Click to expand...
Click to collapse
yups code needs some more patching but i am sure this is the way forward for stable overclock
I've got the basics working with a completely reworked sysfs interface (no module). See GitHub.
The idea is simple: At all times, there shall be no more than 4 OPPs enabled. For each overclock "wish", we disable the currently highest OPP, and enable the overclocked one. If this has no corresponding OPP yet, we create it.
The code works, and has the following problems / features:
Only the highest OPP can be set for now. Consequently, the overclock has to be higher than 800 MHz.
The voltage is not adjusted, yet. All overclock frequencies are run with the 1 GHz stock voltage.
The cpufreq table, policy and stats are not updated, yet
The cpu does not go into deep sleep after the clocks have been adjusted (possibly because the cpufreq table is wrong)
As OPPs are added to the table if necessary, it is theoretically possible to max out the OPP array by defining new frequencies hundreds of times (depending on the maximum array size).
To set the frequency (in MHz), type
Code:
echo "1100" > /sys/power/overclock_max_freq
It would be really cool if you could take a look, DooMLoRD. The only real problem I see right now is the cpufreq table. If this would be correctly updated, the rest would be "easy" I tried some stuff (not in the commit), but nothing worked, yet.
XDA_Bam said:
I've got the basics working with a completely reworked sysfs interface (no module). See GitHub.
The idea is simple: At all times, there shall be no more than 4 OPPs enabled. For each overclock "wish", we disable the currently highest OPP, and enable the overclocked one. If this has no corresponding OPP yet, we create it.
The code works, and has the following problems / features:
Only the highest OPP can be set for now. Consequently, the overclock has to be higher than 800 MHz.
The voltage is not adjusted, yet. All overclock frequencies are run with the 1 GHz stock voltage.
The cpufreq table, policy and stats are not updated, yet
The cpu does not go into deep sleep after the clocks have been adjusted (possibly because the cpufreq table is wrong)
As OPPs are added to the table if necessary, it is theoretically possible to max out the OPP array by defining new frequencies hundreds of times (depending on the maximum array size).
To set the frequency (in MHz), type
Code:
echo "1100" > /sys/power/overclock_max_freq
It would be really cool if you could take a look, DooMLoRD. The only real problem I see right now is the cpufreq table. If this would be correctly updated, the rest would be "easy" I tried some stuff (not in the commit), but nothing worked, yet.
Click to expand...
Click to collapse
this is the same problem as with other overclocks i was playing with...
the cpufreq table doesnt get updated... only the module based way seems to change that table...
anyways we will have to investigate this further...
oh btw i have found patch to overclock GPU...
DooMLoRD said:
oh btw i have found patch to overclock GPU...
Click to expand...
Click to collapse
Nice. Hehe
As I cannot find any related guide while google-ing, I want to post this question on here for the purpose of learning and probably helping other people.
[Q1] How to overclock a kernel
which files are needed -> kernel source .. ?
what files need to be edited ?
is the cpufreq driver related ?
how to determine which frequencies need higher voltage and how high exactly ?
[Q2] Undervolting
which files are needed -> kernel source .. ?
what files need to be edited ?
is the cpufreq driver related ?
how to determine which frequencies can use lowered voltage and how to calculate them ?
I would be very thankful if any developer could teach me (probably others too) and I will contribute back for sure.
I am right now fixing up bugs in TeamGummy rom, and I'm nearly finished.
Only thing I lack is a custom kernel, which I want to build myself along with the rom.
*push*
Watch out guys, master guevor is going to teach us a little of his enormous knowlegde, so better keep your eyes on this one.
Overclocking
I must say that all I'm going to write, is what I've gathered looking at the code and changes made by others (thanks Blades and Roach2010) (I have not had any documentation about it), so I could make mistakes or misinterpretation.
Nor do I explain everything, because if you do not have a minimal knowledge get to play this directly may be dangerous.
(Q1) Overclocking
Files to modify
arch/arm/mach-tegra/tegra2_clocks.c (All matters relating to the frequencies.)
The system uses a series of programmed pll clocks which in turn can be used as a basis to other clocks. Let's say for this case pll_x is used for the base of processor clock.
The frequency table are in tegra_pll_x_freq_table processor. Seeing the type definition clk_pll_freq_table in clock.h we know that has entries consisting of 6 values. (input_rate, output_rate, n, m, p, cpcon)
These values allow tegra2_pll_clk_set_rate function to set the pll frequency.
The values of interest are the frequency of input and output that indicates the input frequency base to be used and what frequency we want to set (it will use the frequency corresponding to the current base and the output frequency we want). m * p values give us the divisor and n is the multiplier. For simplicity we say that n/(m*p) will give us the multiplier, which applied to the base frequency will give the target frequency.
So if we want to add new frequencies, we must add entries in this structure (tegra_pll_x_freq_table) so the system knows how to program a frequency we want to use.
Add 4 entries for each frequency we want to add (one for each base frequency: 12000000,13000000,19200000,26000000 in our case), with multipliers/dividers to calculate the frequency for which we are adding.
If we add higher frequencies than at present, we have to change the maximum (max_rate) in the tegra_clk_virtual_cpu and tegra_clk_cclk structures, otherwise the system will ignore it. Also have to change the limits for our type of processor in sku_limits. For this case the cpu, cclk y pll_x in the values for our processor (0x04, 0x08, 0x0F).
Finally we modify the table of frequencies used by the processor (frequency list and their order). Is defined at cpufreq_tables and contains a list of lists where we can add a new list or not to touch anything and modify an existing list.
We can look at the existing list freq_table_1p2GHz or in my source I added the list freq_table_1p7GHz.
Contains a list of frequencies that the system can select. It uses the list whose maximum corresponds to the maximum indicated above.
arch/arm/mach-tegra/tegra2_dvfs.c (Everything related to the voltages and its relationship with the frequencies.)
This part is much more sensitive and therefore can affect much to the duration of the battery as to stability. I have no formula (unfortunately for me) on how to modify the values, so the task has been more trial and error.
The first thing to know is that one must distinguish between the core voltage and the cpu and should be the latter inferior to the first. In tegra2_dvfs_rel_vdd_cpu_vdd_core function establishes the relationship between the two, being the default 120mV core above the cpu.
Basically what we do if we have added frequencies higher than normal, is to increase the voltage so that they are stable (depend on each processor). I recommend (at first) increment in the same extent all the values involved (maximum voltage).
Therefore we can modify:
Table core_millivolts, establishing the voltages that core can use.
Table cpu_millivolts, establishing the voltages that cpu can use. It contains all the steps and should take into account the difference with the core discussed earlier. If we added any frequency, we add the corresponding voltages.
Tables core_speedo_nominal_millivolts and cpu_speedo_nominal_millivolts contain a nominal voltage of both the core and the cpu.
The maximum and nominal voltages in structures tegra2_dvfs_rail_vdd_cpu, tegra2_dvfs_rail_vdd_core and tegra2_dvfs_rail_vdd_aon.
Finally we adjust the settings for dvfs_init ("cpu", 1,) according to the list of frequencies we want to use (adding if we added new frequencies or changing them if changed change some)
With these changes we should be able to overclock, although we know that although you can configure (once started) a maximum frequency below the maximum that we put on the tables, there is a problem and many times after suspending the system will use the maximum frequency of the table. To avoid this we must make some changes in cpufreq.c
drivers/cpufreq/cpufreq.c
The problem occurs in the second core when reconnected after being disconnected in the suspension process. The problem is solved with the next patch.
Code:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e157205..2626e2d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1048,18 +1048,27 @@ static int cpufreq_add_dev(struct sys_device *sys_dev)
/* Set governor before ->init, so that driver could check it */
#ifdef CONFIG_HOTPLUG_CPU
+ struct cpufreq_policy *cp;
for_each_online_cpu(sibling) {
- struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
+ cp = per_cpu(cpufreq_cpu_data, sibling);
if (cp && cp->governor &&
- (cpumask_test_cpu(cpu, cp->related_cpus))) {
+ (cpumask_test_cpu(cpu, cp->related_cpus))) {
+ dprintk("found sibling CPU, copying policy\n");
policy->governor = cp->governor;
+ policy->min = cp->min;
+ policy->max = cp->max;
+ policy->user_policy.min = cp->user_policy.min;
+ policy->user_policy.max = cp->user_policy.max;
found = 1;
break;
}
}
#endif
if (!found)
+ {
+ dprintk("failed to find sibling CPU, falling back to defaults\n");
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+ }
/* call driver. From then on the cpufreq must be able
* to accept all calls to ->verify and ->setpolicy for this CPU
*/
@@ -1071,6 +1080,16 @@ static int cpufreq_add_dev(struct sys_device *sys_dev)
policy->user_policy.min = policy->min;
policy->user_policy.max = policy->max;
+ if (found)
+ {
+ /* Calling the driver can overwrite policy frequencies again */
+ dprintk("Overriding policy max and min with sibling settings\n");
+ policy->min = cp->min;
+ policy->max = cp->max;
+ policy->user_policy.min = cp->user_policy.min;
+ policy->user_policy.max = cp->user_policy.max;
+ }
+
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_START, policy);
Ok, I'm on it. Trying my best, but I'm afraid you have to push me a little..
Facing heavy compile errors.
Question :
In your kernel source dir, which command do you use to start compiling ?
EDIT :
EDIT 2 :
@ all people trying to compile, do NOT use
Code:
make tegra_defconfig
!
Better grab an existing .config file from an already running kernel (thanks to guevor for this)
Just google "cyanogenmod building kernel from source" , it's described well over there.
If people request, I can share the kernel config and the precompiled blob tools once I get them from guevor.
First kernel compiled successfull, I have my zImage ready.
OC'd and Voltages changed.
First test kernel incoming the next days, I could need some testers.
Pm me if you want to test.
Thanks for this! I love your work and you sharing your vast knowledge of this subject! Thanks OP for giving him the means of enlightening us
back from the dead
edited
I was a little sleep deprived... my bad
Necromancy!
Say I want to just simply modify my cpu_max_freq via my stock kernel (no source availabel) and I have the boot.img and have unpacked it to boot.img-kernel. What should I do from here to get into the internals of the kernel to adjust the cpu_max_freq? I'm running an ARM Cortex A9, the same as the Tegra2 cpu per say.
Thanks
1chris89 said:
Say I want to just simply modify my cpu_max_freq via my stock kernel (no source availabel) and I have the boot.img and have unpacked it to boot.img-kernel. What should I do from here to get into the internals of the kernel to adjust the cpu_max_freq? I'm running an ARM Cortex A9, the same as the Tegra2 cpu per say.
Thanks
Click to expand...
Click to collapse
You can't do it that way. You can try to create oc modules but I couldn't tell you how to do that
Sent from my EVO using Tapatalk 2
Can you send me in the right direction?
Looks like unpacking the kernel isn't happening but I can create an overclock module which is FAR from easy but here's something I started on a little not sure if it's specific to the other device or whatever but I'll see how it goes.
http://forum.ppcgeeks.com/android-t...modules-tinboot-nand-boot-more-beginners.html
1chris89 said:
Say I want to just simply modify my cpu_max_freq via my stock kernel (no source availabel) and I have the boot.img and have unpacked it to boot.img-kernel.
Click to expand...
Click to collapse
Since the kernel is under GPL, get the sources from where you got the binary.
1chris89 said:
I'm running an ARM Cortex A9, the same as the Tegra2 cpu per say.
Click to expand...
Click to collapse
Is it a Tegra 2 or not? If not, this thread won't help you.
I don't understand this part:
The values of interest are the frequency of input and output that indicates the input frequency base to be used and what frequency we want to set (it will use the frequency corresponding to the current base and the output frequency we want). m * p values give us the divisor and n is the multiplier. For simplicity we say that n/(m*p) will give us the multiplier, which applied to the base frequency will give the target frequency.
So if we want to add new frequencies, we must add entries in this structure (tegra_pll_x_freq_table) so the system knows how to program a frequency we want to use.
Add 4 entries for each frequency we want to add (one for each base frequency: 12000000,13000000,19200000,26000000 in our case), with multipliers/dividers to calculate the frequency for which we are adding.
Click to expand...
Click to collapse
I want to add new frequencies but I don't get it.. also, why 4 entries for a single frequency? thanks!
Someone pleaseeee?
I hope there's a video tutorial for "adding overclocking features to your kernel", I hate to admit that I can't follow the instructions carefully due to lack of English knowledge
Collective guide of CPU governors, I/O schedulers and other kernel variables
I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel tuning, please note that I am not responsible for any damage to your device or malfunction. You are in complete control over your device so please do not blindly follow without proper research. While you could use this guide to tune other devices other than a smartphone, I would recommend against doing so.
Guides:
Governors - Part 1: Post 1
Governors - Part 2: Post 2
I/O Schedulers: Post 3
CPU Governor Tuning Guide: Post 4
I/O Scheduler Tuning Guide: Post 5
Hotplug Driver Tuning Guide: Post 6
TCP Algorithms: Post 7
Other Important Information: Post 8
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:
OnDemand
OnDemandX
Performance
Powersave
Conservative
Userspace
Min Max
Interactive
InteractiveX
Smartass
SmartassV2
Scary
Lagfree
Smoothass
Brazilianwax
SavageZen
Lazy
Lionheart
LionheartX
Intellidemand
Hotplug
Badass
Wheatley
Lulzactive
PegasusQ\PegasusD
HotplugX
Abyssplug
MSM DCVS
Intelliactive
Adaptive
Nightmare
ZZmove
Sleepy
Hyper
SmartassH3
SLP
NeoX
ZZmanX
OndemandPlus
Dynamic Interactive (DynInteractive)
Smartmax
Ktoonservative\KtoonservativeQ
Performance may cry (PMC)
Dance Dance
AbyssPlugv2
IntelliMM
InteractivePro
Slim
Ondemand EPS
Smartmax EPS
Uberdemand
Yankactive
Impulse
Bacon
Optimax
Preservative
Touchdemand
ElementalX
Bioshock
Blu_active
Umbrella_core
ConservativeX
Hyrdxq
DevilQ
Yankasusq
Darkness
Alucard
Hellsactive
Ragingmolasses
Virtuous
Sakuractive
InteractiveX v2
Alessa
GallimaufryX
AggressiveX
Tripndroid
Wrexy
Xperience
Stockdemand
Zeneractive
InteractiveB
Aggressive
IntellidemandV2
Boostactive
Wave
Barry-Allen
Arteractive
Precognition (PrecoGOV)
Mythx_plug
PegasusQPlus
Yankdemand
HyperX
Despair
Electroactive
Electrodemand
Lionfish
Interextrem
Cafactive
Lightning
ThunderX
sched-DVFS
Intel
Frankenstein
Cyan
TheSSJactive
Chill
sprdemand
Kraken
Ironactive
Nebula
Relaxed
Crazyactive
thenewbeginning
Cultivation
Schedutil
pwrutilx
blu_schedutil
Descriptions:
HMP Governors
1: OnDemand:
Description:
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, 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.
2: OndemandX:
Description:
Basically an ondemand with suspend/wake profiles. No further optimization was done to Ondemand to keep it close to source as possible.
3: Performance:
Description:
The performance governor locks the phone's CPU at maximum frequency.
4: Powersave:
Description:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5: Conservative:
Description:
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". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.
6: Userspace:
Description:
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
Description:
Min Max is a governor that makes use of only min & maximum frequency based on workload... no intermediate frequencies are used!
8: Interactive:
Description:
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. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
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:
Description:
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
Description:
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:
Description:
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.
12: Scary
Description:
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.
13: Lagfree:
Description:
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:
Description:
The same as the Smartass “governor” But MUCH more aggressive & across the board.
15: Brazilianwax:
Description:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Description:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
Description:
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:
Description:
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
Description:
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Description:
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) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off. Faux no longer recommends intellidemand and believes that intellidemand users should switch to intelliactive for better optimizations and performance.
21: Hotplug:
Description:
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:
Description:
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 to max frequency, If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Description:
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:
Description:
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
Description:
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
Description:
It's a modified version of Hotplug and optimized for the suspension in off-screen
27: AbyssPlug
Description:
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
Description:
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
Description:
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.
Created by Faux
30: Adaptive
Description:
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
Description:
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: ZZmoove
Description:
The ZZmoove 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. The unique feature with ZZmoove is that it has predefined profiles and allows profile switching.
33: Sleepy
Description:
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
Description:
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
Description:
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
Description:
It is a mix of pegasusq and ondemand. Therefore, it has a balance between battery savings and performance.
37: NeoX
Description:
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
Description:
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
Description:
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. Dynamic Interactive (DynInteractive)
Description:
This governor dynamically adjusts itself according to load. That means it's settings are dynamic (always changing) and not static (not changing). Dyninteractive still obtains the same great balance between battery life and performance found in the original interactive governor and improves it even further. This is not the same as the original interactive governor because of this unique behavior.
41. Smartmax
Description:
Smartmax is a mix between ondemand and smartassv2. It behaves mostly like smartass with the concept of an "ideal" frequency. By default this is configured for battery saving, so this is NOT a gaming or benchmark governor! Additionally, to make it "snappy", smartmax has "touch poke". So input events from the touchscreen will boost the cpu for a specific time to a specific frequency. Developed by XDA user Maxwen.
42. Ktoonservative\KtoonservativeQ
Description:
Ktoonservative is based on the Conservative governor, but with the addition of new tunable variables and hotplugging. It aims to be very responsive while also being good at saving battery. This governor is highly configurable and is found in ktoonsez's kernels.
43. Performance may cry (PMC)
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
Ondemand based with 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
Description:
Preservative is a conservative based 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
Description:
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
Description:
By default, it is more conservative than Ondemand as it does not ramp up often for most phone activities. If there is a graphics load detected, the governor will switch to a two-phase Ondemand behaviour where different max frequencies are used depending on the load increase. ElementalX comes with input boost enabled by default lowering the sampling rate and increasing the frequency to improve responsiveness.
59. Bioshock
Description:
CPU governor developed by Jamison904. A mix of ConservativeX and Lionheart
60. Blu_active
Description:
A 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
Description:
A 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
Description:
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
Description:
Simply a lulzactiveq governor with tweaks to performance (thanks to tegrak). This means more performance and less battery life.
64. DevilQ
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
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
Description:
A modded ondemand that is a 2-stage ondemand governor with speed tweaks. It includes imoseyon's screen-off hotplugging code.
75. AggressiveX
Description:
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
Description:
Tripndroid is based on ondemand with extra tweaks for performance
77. Wrexy
Description:
Wrexy is a conservative based governor but is also similar to the Lionheart gov. It tends to stay out of higher frequencies to favor lower frequencies but performance is not much affected.
78. Xperience
Description:
A tweaked smartassv2 for better performance. Created by TeamMex.
79. Stockdemand
Description:
A heavily modified ondemand for better performance and battery life.
80. Zeneractive
Description:
Based on the interactive governor, it handles frequency scaling the exact same as interactive and has the same tunables as interactive for frequency scaling. However, all of the new hotplugging code is written "from scratch."
81. InteractiveB
Description:
An interactive based governor with a more balanced battery life/performance profile
82. Aggressive
Description:
Like Lionheart, it is based on conservative, but even more aggressive
83. Intellidemandv2
Description:
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
Description:
Based on Interactive but with cpu frequency boosting capabilities. This is performance oriented governor.
85. Wave
Description:
Based on Conservative with some tweaks for speed and battery. This governor was created by zparallax.
86. Barry-Allen
Description:
It's based on interactive. The governor is supposed to be more battery friendly and at the same have good performance.
87. Arteractive
Description:
It is an interactive CPU governor port from newer source code. It has more optimizations for Snapdragon 80x processors.
88. Precognition (PrecoGOV)
Description:
PrecoGOV takes over and dynamically adapts to your usage pattern. To achieve such goal, PrecoGOV manages the frequency, idle & sleep patterns, hotplugging, temperature per core and even gpu and tries to help the scheduler as best as it can, all while taking into account battery and thermal constraints.
89. Mythx_plug
Description:
It's based on an improved Interactive governor and has been modified to scale up slower and scale down faster. It is a battery friendly governor.
90. PegasusQPlus
Description:
PegasusQPlus is a heavily tweaked PegasusQ governor, which has been implemented by AndreiLux in his Perseus kernel. PegasusQPlus should have a better balance between performance and battery usage.
91. Yankdemand
Description:
Full stock (JB) ondemand governor with changed default tunable values aimed at lower battery consumption
92. HyperX
Description:
A tweaked interactive based governor for performance.
93. Despair
Description:
It is a tweaked conservative governor with a couple extra values exposed, it tends to be a bit more conservative with battery than the conservative governor by default. Developed by DespairFactor.
94. Electroactive
Description:
This governor is the replacement over the original electrodemand governor, being much more battery friendly with much smoother transitions compared to the original. It is a hybrid class governor, using a unique way to merge the best of both interactive and ondemand. It includes some extra additions and enhancements to be more battery saving than interactive governor and some boost tunes and additions that allow better power management and performance in games as well as better power saving when in normal use. CPU boost, graphics boost, fast_start deep_sleep and detection features are built in as well as 300 MHz clock speed in suspend.
95. Electrodemand
Description:
Based on the ondemand cpu governor, this is the older governor that was used in the electroactive kernel which uses the same tunables found in the original ondemand governor.
96. Lionfish
Description:
The Lionfish governor combines traits of the conservative, ondemand, and interactive governors. It is designed to maximize battery life without noticeably impacting performance. It responds quickly to heavy loads while staying within the region of optimal CPU performance per watt. With moderate loads, it periodically votes to raise, maintain, or decrease the frequency. When there are enough votes to change the frequency, it is ramped up and down gradually. The voting mechanism reduces frequency jitter compared to ondemand and conservative. squid2's testing had found that this governor uses moderate frequencies (where efficiency is optimal) more effectively than interactive, ondemand, and conservative. This improved frequency distribution results in a moderate reduction in CPU power consumption while maintaining responsiveness comparable to the interactive governor.
97. Interextrem
Description:
A tweaked interactive governor by thehacker911. It is found in hacker kernel s6, where it has been tuned for better performance while still maintaining good battery life.
98. Cafactive
Description:
Found in arter97's kernels, cafactive is the qualcomm optimized version of interactive from CodeAurora. This version promises to bring greatly enhanced performance over samsung's own version of interactive (benchmarks have shown a increase in performance scores), however it may be unstable on some devices and may cause some performance issues under normal and heavy operation.
99. Lightning
Description:
Lightning is modified darkness gov made by @HridayHS
100. ThunderX
Description:
ThunderX is a power saving CPU governor based on SmartAssv2 optimized for Mediatek SoCs.
101. Intel
Description:
It's an interactive based governor that is optimized for Intel devices. It is thought to be more battery friendly than interactive while still having good performance. Found only on intel based SOCs.
102. Frankenstein
Description:
Based on interactive with hotplugging, it is a performance oriented governor but aims to save battery when screen is off. However, it may be unstable on some devices. Found only on intel based SOCs.
103. Cyan
Description:
Cyan is an interactive based CPU governor intended for heavy gaming and processes. It was originally developed for the i9500, but is now found in kernels for devices with intel SOCs.
104. TheSSJactive
Description:
TheSSJactive is based on yankactive but with the addition of hotplugging support for intel SOCs. It is known to be a battery friendly governor.
105. Chill
Description:
A conservative based governor by frap129 (Electron kernel). It's aims to provide more aggressive battery savings while screen is off.
106. sprdemand
Description:
A modded ondemand governor with functionality to offline CPUs when screen is off. It has thermal control logic implemented into the governor.
107. Kraken
Description:
Based on ElementalX but with tweaks for better performance while remaining well balanced. Found in Kraken Kernel by Team OctOS.
108. Ironactive
Description:
Based on the latest CAF 4.4 version of interactive without any additional modifications. It is found in @Tkkg1994's superkernel for the Samsung Galaxy S7.
109. Nebula
Description:
A port of the Interactive governor based on msm-4.4 sources with some mods for the HTC 10, preserving the excellent balance between performance and battery life found in many other Interactive based govs. It originated from Eliminater74's Nebula kernel and was a popular choice prior to the introduction of EAS scheduling to the kernel.
110. Relaxed
Description:
Relaxed is based on chill, and has been altered in order to achieve more gradual frequency boosting providing battery life benefits. Relaxed uses a boost ceiling variable in order to achieve this. Rather than boosting straight to the max frequency, relaxed finds the difference between boost_counter and boost_ceiling, then boosts to max minus that difference. This governor doesn't completely replace chill, but is intended to be used alongside it.
111. Crazyactive
Description:
A modified Interactive governor by @CrazyGamerGR that has been biased more towards performance.
112. thenewbeginning
Description
A modified Alucard governor by varunhardgamer that has been biased more towards performance.
113. Cultivation
Description
A highly modified interactive-based governor with the intention of giving the user more control by providing more tuning options. Based on CAF 4.4 commits with parts coming from blu_active and XDA user Sultanxda.
EAS Governors
114. schedutil
Description:
schedutil is a new EAS governor found in recent versions of the Linux Kernel (4.7+) that aims to integrate better with the Linux Kernel scheduler. It uses the kernel's scheduler to receive CPU utilisation information and make decisions from this input. As a direct result, schedutil can respond to CPU load faster and more accurate than normal governors such as Interactive that rely on timers.
115. pwrutilx
Description:
A new EAS governor based on schedutil that aims to be much more efficient by using a different formula to get next frequency.
116. blu_schedutil
Description:
blu_schedutil is an unmodified version of the Pixel 3 schedutil governor which promises better battery savings over traditional schedutil.
Hotplugging drivers:
1. mpdecision:
Description:
Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
2.msm_hotplug:
Description:
Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
3. intelliplug:
Description:
A popular hotplug from faux123 that is highly customisable and provides a great balance between battery and performance.
4. Alucard:
Description:
A great hotplugging driver by Alucard. It is known to be very battery friendly on devices.
5. Kt Auto Hotplug:
Description:
A great hotplug driver by Ktoonsez. Pretty much a smarter mpdecision that has been optimized for quad-core devices.
6. Mako Hotplug:
Description:
A popular hotplug driver found in Franco kernel. Franco didn't like how closed sourced MPdecision worked and so he created this driver as a direct replacement. It always keep 2 cores online and will online additional cores based on load conditions.
7. Zen Decision:
Description:
ZEN only onlines all cores when screen is on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you can't change its behavior.
8. Bricked Hotplug:
Description:
Conservative hotplug driver by @show-p1984. It is based on mpdecision but has been optimized for better balance between battery life and performance.
9. msm_sleeper:
Description:
The main feature with this hotplug is that you can customize the screen off frequency. Two cores are always on, the third and fourth are independent and come online if needed. By default, if the load is over 80 for 400ms another core comes online. The third and/or fourth cores stay online as long as the load demands it or for a minimum of one second. While the screen is off, it goes down to a single core. Created by flar2.
10. Autosmp:
Description:
A highly-efficient hotplug driver by @mrg666, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
11. Thunderplug:
Description:
A matured load-based hotplug driver with many tunables written from ground up by varun.chitre15. This hotplug is optimized for octa-core devices and also has support for 64bit CPUs.
12. Blu_plug:
Description:
Dynamic hotplug from eng.stk's shamu kernel with screenoff battery saving.
13. cpuquiet:
Description:
A hotplug driver by NVidia and ported to Snapdragon by maxwen. Originally made for NVidia tegra SOCs. It has a set of governors which keep the CPU running at optimal frequencies for battery and performance.
14. Fast hotplug:
Description:
A hotplug driver from pec0ra's abricot kernel. It aims to be as lightweight as possible while also being highly customizable. However, it is still a WIP as it is known to have some stability issues.
15. Hima hotplug:
Description:
An optimized hotplug driver based on intelliplug for big.LITTLE architecture. Found on chadouming's HTC One (M9) kernel, it takes advantage of the big and LITTLE CPU cores in order to provide 'butter smooth' performance.
16. State Helper:
Description:
A hotplug driver by @neobuddy89 designed with the Nexus 6 in mind. It is highly configurable giving the user control over what CPUs to online based on what battery threshold levels have been set. Another feature that sets state helper apart from other hotplug methods is that it respects the thermal driver.
17. ZZmoove native hotplug:
Description:
The hotplugging logic found in the ZZmoove governor. This isn't a standalone hotplug driver that can be used with other governors, the hotplugging is done by the governor which was common on older devices like the Samsung Galaxy S3. Native hotplugging may offer better stability and the governor should perform better in battery life and performance (your experience may vary) because it was designed for this specific governor.
18. Lazyplug
Description:
A hotplug from arter97 that leaves CPU cores on for most of the time with the exception of some situations where leaving all cores on could be battery draining (e.g. Video playback). The purpose behind this is to improve performance & battery life by removing excess CPU overheads caused by unnecessary hotplugging where similar techniques are already employed in Samsung and Nexus firmwares.
GPU governors
1. Simple:
Description:
An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.
2. simple_ondemand:
Description:
As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
3. msm-adreno-tz:
Description:
The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
4. Performance:
Description:
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.
5. Powersave:
Description:
Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
6. Adreno Idler:
Description:
It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
7. Userspace:
Description:
This governor basically allows the user is able to set a desired frequency for the GPU to run at.
8. cpubw_hwmon:
Description:
A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.
9. MSM Cpufreq:
Description:
The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.
Benchmark graphs:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Link to raw data: https://drive.google.com/file/d/0B3ApZsjOd2bzWDRnQjRsUTlLSlE/view?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/showthread.php?t=2768979
Recommendations
Overall:
Interactive (or balanced variants)
zzmoove (default or optimized profile)
Ondemand
PegasusQ (Works well on some older devices)
Impulse
Battery Saving:
Conservative (tuned, or battery saving variants)
Ondemand (tuned, or battery saving variants)
Smartmax
Powersave
Alucard
zzmoove (tuned, change to battery profile)
Performance oriented:
Interactive (tuned, or performance oriented variants)
Intelliactive (preferred over intellidemand)
Performance
Nightmare
Blu_active
Lionheart
I/O Schedulers
Why change your phones I/O Scheduler?
Most phone manufacturers keep your phone's I/O scheduler 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?
CFQ
Deadline
VR
Noop
BFQ
FIOPS (Fair IOPS)
SIO (Simple I/O)
ROW
ZEN
SIOplus
FIFO (First in First Out)
Tripndroid
Test
Maple
I/O Scheduler Descriptions:
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. 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:
- Generally performs the best in throughput tests
- Very stable, is the default Linux kernel I/O scheduler for many desktops and mobile devices
- Performs well on spinning storage and even on solid state storage for mixed workloads
- Generally seen as well balanced
- Processes requiring more I/O resources can be prioritised higher (such as indexing, system maintenance)
Disadvantages:
- I/O latency can be somewhat poor
- There is some scheduling overhead, although probably not too noticeable in tests and real world usage
The bottom line: One of the best all-rounder I/O schedulers available. CFQ is better suited for traditional hard disks, however it may give better throughput under some situations.
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:
- Excels in reducing latency of any given single I/O
- Can perform better than CFQ in certain workloads
- Performs well in (most) benchmarks
- Generally low scheduling overhead
- Very stable, default in recent Linux kernel versions
Disadvantages:
- Less I/O throughput than CFQ
- No ability to prioritise I/O bound processes over others
The bottom line: A good all-round scheduler. If you want good performance, you should try deadline.
ROW:
The ROW I/O 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 I/O 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:
- Low read latency, better for responsiveness and task switching
- Generally stable, has been adopted in many kernels
Disadvantages:
- Potentially higher write latency, reducing write performance
The bottom line: It is a good all-round scheduler despite being biased to read operations. Your device may feel more responsive after selecting ROW because it was designed for mobile devices. Older devices may see more of a boost in performance compared to newer devices.
SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between Noop & deadline. No reordering or sorting of requests.
Benefits:
- Generally low I/O latency, better for responsiveness
- Very stable
Disadvantages:
- Performs poorly in benchmarks
The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.
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:
- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives
Disadvantages:
- Performs poorly in benchmarks
The bottom line: Modern smartphones now use Noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.
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:
- Sometimes unstable and unreliable
The bottom line: Not the best scheduler to select. You will probably find that other schedulers are performing better while being more stable.
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:
- Good I/O throughput, sometimes matching CFQ in performance
- Better I/O latency than CFQ, better responsiveness
- Well balanced, even more so than CFQ
- Generally stable, default in some custom kernels and Linux distributions
Disadvantages:
- Performs poorly in benchmarks, sometimes a lot worse in some areas
The bottom line: There are better schedulers out there that will perform better than BFQ. It is quite a complex scheduler that is better designed for traditional hard disks.
ZEN:
ZEN is based on the Noop, Deadline and SIO I/O schedulers. 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 Noop blended with VR features.
Benefits:
- Excels in I/O latency, good for responsiveness
- Very stable
- Generally seen as well balanced
Disadvantages:
- There is some scheduling overhead, but less than CFQ
The bottom line: It is pretty much a better version of VR, performs quite well and is stable. Overall this is a good choice for most smartphones.
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 I/O latency than SIO in certain workloads
Disadvantages:
- Still performs about the same as SIO in benchmarks
The bottom line: If you liked SIO, you will like SIOplus. It performs slightly better in some usage case scenarios, but performance seekers should look else where.
FIOPS (Fair IOPS):
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. FIOPS (Fair IOPS) I/O scheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
Benefits:
- Generally has good I/O latency, performs well in some benchmarks
- Like CFQ, has some scheduling overhead
Disadvantages:
- On certain configurations, people may experience issues with stutters in day-to-day device usage
- Not the most stable scheduler
The bottom line: Most people who use FIOPS will get a noticeable performance improvement. However, you may get issues with scrolling and general lags.
FIFO (First in First Out):
First in First Out Scheduler. As the name says, it implements a simple priority method based on processing the requests as they come in.
Benefits:
- Low I/O latency, better responsiveness
- Very low scheduling overhead
- Very stable, used as default for some systems with solid state drives
Disadvantages:
- Performs poorly in benchmarks
The bottom line: Like Noop, but is less common. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons), you can select this.
Tripndroid:
A new I/O scheduler based on Noop, deadline and vr and meant to have minimal overhead. Made by TripNRaVeR
Benefits:
- Excels in I/O latency, good for responsiveness, sometimes better with some tuning
- Should be stable, however is not adopted widely
- Generally seen as well balanced
Disadvantages:
- There is some scheduling overhead, but less than CFQ
The bottom line: Tripndroid isn't very common. There are other schedulers you can choose which may perform similar or better. However it is a good all-round scheduler.
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, but can be beneficial to kernel developers
Disadvantages:
- Same as Noop
The bottom line: Shouldn't really be used by anyone. You should be using Noop instead of this.
Maple:
Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.
Benefits:
- Well rounded
- Designed for mobile devices in mind
- Better I/O latency than ZEN in certain workloads
Disadvantages:
- May be unstable on some devices
The bottom line: This is still a very new I/O scheduler which should perform slightly better than ZEN. It will continue to improve with more development.
Anxiety:
Anxiety doesn't separate asynchronous and synchronous requests because asynchronous ones are rarely seen. It prioritizes reads over writes just like Maple, but tends to starve writes more (this is tunable). It is based on noop with a basic first-in-first-out algorithm, whereas Maple is based on deadline with time tracking for expiration. This makes Anxiety better on battery than Maple, as well as fast. It prioritizes latency over throughput which means that requests happen quicker but transfer data slower.
Benefits:
- Designed for mobile devices in mind
- Possibly more battery savings compared to Maple
Disadvantages:
- Data transfers and write speeds may be slower
Multi-queue schedulers:
If you have a fairly recent phone, the chances are that you are able to use multi-queue (MQ) I/O schedulers. It comes from recent works from the upstream Linux kernel as devices are becoming more powerful with better storage and processors. These schedulers in theory should perform better than your traditional schedulers (e.g. noop, SIO, etc), by having better utilisation of multi-core CPUs/SOCs. You can have a view of some of the descriptions here: Arch Linux wiki.
The bottom line: A good well-rounded I/O scheduler that is relatively simple and performs quite well in most scenarios.
I/O Read Ahead Buffer:
If you've used a custom kernel, you probably have heard of a term called Read Ahead Buffer or Cache. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more buffer means that more files can be cached, this can mean higher read and write speeds, but also this can result in more I/O latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.
Have a look at the graph below:
Source: http://andrux-and-me.blogspot.com.au/2014/06/various-conditions-and-io-performance.html
Recommendations:
I/O Read Ahead Buffer is dependent on the size of your flash storage (internal/external) unlike I/O schedulers. Below is the recommended settings for the given size that will yield the best performance (differs between setups).
Less than 8GB - 128KB
8GB - 512KB
16GB - 1024KB
32GB or above - 2048KB
Any setting above what I have recommended may yield no extra performance!
If you have issues such as failed reads and writes after changing these values, try a smaller value. Please note that some SD cards may experience issues after setting a higher buffer value.
What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Performance difference varies between devices
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/showpost.php?p=58807943&postcount=85
Recommended IO schedulers:
Overall:
- CFQ
- BFQ
- FIOPS
- Deadline
Justification: For overall performance, evidence has shown that some form of scheduling such as seen in CFQ or BFQ is beneficial not only for mechanical drives, but also for solid state media [citation needed]. These schedulers are usually configured to understand the differences between the storage devices, and hence for example will not treat Internal Storage as a traditional rotating hard drive(based on seeks). In smartphones, we do a lot of concurrent I/O multitasking, and hence, schedulers that have some logic to impose fairness will help in this situation
For best performance:
- FIOPS
- BFQ
- CFQ
- Deadline
Justification: Results have shown that schedulers such as CFQ (those that impose some form of fairness) achieve excellent throughput, but the cost of increase scheduling overhead and latency. On modern smartphones, added overhead and latency shouldn't have a significant impact to the responsiveness of the system, since we are dealing with much more powerful CPUs than those of the past. Synthetic benchmarks should not be the deciding factor of a scheduler
For least overhead:
- Noop
- FIFO
- Deadline
Justification: If the only thing you value is lower overheads on I/O processing, your best bet is Deadline. Why? Noop has been recommended on some guide found on the internet for solid state media, however there are known cases where Noop has caused issues in some particular workloads [citation needed]
Source: xda-developers, andrux-and-me.blogspot.com.au
CPU Governor tuning guide
NOTE: If you don't have some of these tunables, you might have an older version of the governor/hotplug driver and/or the kernel maintainer has made modifications to it.
CPU governors
1. ONDEMAND
[ PARAMETERS ]
i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
ii) up_threshold - defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '95' it means that between the checking intervals the CPU needs to be on average more than 95% in use to then
decide that the CPU frequency needs to be increased.
iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
iv) sampling_down_factor - Determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. T
v) down_differential - Indirectly calculates the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential).
vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336.
vii) ignore_nice_load - this parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency.
viii) sampling_rate_min -
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
If CONFIG_NO_HZ is set, the limit is 10ms fixed.
If CONFIG_NO_HZ is not set or nohz=off boot parameter is used, the
limits depend on the CONFIG_HZ option:
HZ=1000: min=20000us (20ms)
HZ=250: min=80000us (80ms)
HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.
Click to expand...
Click to collapse
2. LULZACTIVEQ
1. Initial Version:-
[ PARAMETERS ]
i) down_sampling_time - Sampling time to scale cpu down.
ii) up_sampling_time - Sampling time to scale cpu up.
Click to expand...
Click to collapse
2. Second Version (LulzactiveQ):-
[ PARAMETERS ]
i) inc_cpu_load - In previous version, this was 'hard-coded' to 60. Now it's user-configurable. The frequency at which governor scales CPU up/down. Load < inc_cpu_load: cpu scaled down. Load >= inc_cpu_load: cpu scaled up
ii) pump_up_step - No of scale up steps when load >= inc_cpu_load
iii) pump_down_step - No of scale down steps when load < inc_cpu_load
iv) screen_off_min_step - Steps in frequency table to be used when screen-off. Example: If available freqs are 1600 1400 1200 1000 800 500 200 100 (L0 to L7) and screen_off_min_step=5 then 100,200 and 500 (L5 to L7) will be used during screen-off depending on the demand.
v) up_sample_time - Sampling time to scale cpu up. (Allowed values 10,000 to 50,000)
vi) down_sample_time - Sampling time to scale cpu down. (Allowed values 10,000 to 100,000)
Click to expand...
Click to collapse
3. SMARTASSV2
[ PARAMETERS ]
i) awake_ideal_freq - The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
ii) sleep_ideal_freq - The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
iii) up_rate_us - The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
iv) down_rate_us - The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
v) max_cpu_load - Same as up_threshold in other governors.
vi) min_cpu_load - Same as down_threshold in other governors.
vii) ramp_down_step - Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
viii) ramp_up_step - Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
ix) sleep_wakeup_freq - The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.
Click to expand...
Click to collapse
4. CONSERVATIVE
[ PARAMETERS ]
Ondemand and conservative have some tunables in common, but with a few extras:
i) freq_step - this describes what percentage steps the cpu freq should be increased and decreased smoothly by. By default the cpu frequency will increase in 5% chunks of your maximum cpu frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make
it behave identically to the "ondemand" governor.
ii) down_threshold - same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
Click to expand...
Click to collapse
5. INTERACTIVE
1. Generic Version
[ PARAMETERS ]
i) hispeed_freq - An intermediate "hi speed" at which to initially ramp when CPU load hits the value specified in go_hispeed_load. If load stays high for the amount of time specified in above_hispeed_delay, then speed may be bumped higher. Default is the maximum speed allowed by the policy at governor initialization time.
ii) go_hispeed_load - The CPU load at which to ramp to hispeed_freq. Default is 99%.
iii) min_sample_time - The minimum amount of time to spend at the current frequency before ramping down. Default is 80000 uS.
iv) timer_rate - Sample rate for reevaluating CPU load when the CPU is not idle. A deferrable timer is used, such that the CPU will not be woken from idle to service this timer until something else needs to run. (The maximum time to allow deferring this timer when not running at
minimum speed is configurable via timer_slack.) Default is 20000 uS.
v) target_loads - CPU load values used to adjust speed to influence the current CPU load toward that value. In general, the lower the target load, the more often the governor will raise CPU speeds to bring load below the target. The format is a single target load, optionally followed by pairs of CPU speeds and CPU loads to target at or above those speeds. Colons can be used between the speeds and associated target loads for readability. For example:
85 1000000:90 1700000:99
targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted. If speeds are specified these must appear in ascending order. Higher target load values are typically specified for higher speeds, that is, target load values also usually appear in an ascending order. The default is target load 90% for all speeds.
vi) above_highspeed_delay - When speed is at or above hispeed_freq, wait for this long before raising speed in response to continued high load. The format is a single delay value, optionally followed by pairs of CPU speeds and the delay to use at or above those speeds. Colons can be used between the speeds and associated delays for readability. For example:
80000 1300000:200000 1500000:40000
uses delay 80000 uS until CPU speed 1.3 GHz, at which speed delay 200000 uS is used until speed 1.5 GHz, at which speed (and above) delay 40000 uS is used. If speeds are specified these must appear in ascending order. Default is 20000 uS.
vii) timer_slack - Maximum additional time to defer handling the governor sampling timer beyond timer_rate when running at speeds above the minimum. For platforms that consume additional power at idle when CPUs are running at speeds greater than minimum, this places an upper bound on how long the timer will be deferred prior to re-evaluating load and dropping speed. For example, if timer_rate is 20000uS and timer_slack is 10000uS then timers will be deferred for up to 30msec when not at lowest speed. A value of -1 means defer timers
indefinitely at all speeds. Default is 80000 uS.
viii) boost - If non-zero, immediately boost speed of all CPUs to at least hispeed_freq until zero is written to this attribute. If zero, allow CPU speeds to drop below hispeed_freq according to load as usual. Default is zero.
ix) boostpulse - On each write, immediately boost speed of all CPUs to hispeed_freq for at least the period of time specified by boostpulse_duration, after which speeds are allowed to drop below hispeed_freq according to load as usual.
x) boostpulse_duration - Length of time to hold CPU speed at hispeed_freq on a write to boostpulse, before allowing speed to drop according to load as usual. Default is 80000 uS.
Click to expand...
Click to collapse
2. Qualcomm version/Intelliactive/IntelliMM
[ PARAMETERS ]
Has some tunables in common with the generic version but with a few extras:
i) Sync_freq Feature - This feature will cause a CPU frequency to stay above a particularvalue sync_freq) if certain conditions (determined by the two nodes up_threshold_any_cpu_freq and up_threshold_any_cpu_load) are satisfied
ii) Sync_freq - Only when both of the above conditions are satisfied will the CPU not drop below this frequency value. The higher this value, the higher the frequency to jump will be when the above conditions are satisfied.
iii) Up_threshold_any_cpu_freq - If the maximum frequency across all the CPUs is higher than or equal to this frequency value, do not let the current CPU fall below sync_freq. The higher this value, the fewer the chances to go to sync_freq.
iv) Up_threshold_any_cpu_load - If the maximum load across all the CPUs is higher than or equal to this load value, do not let the current CPU fall below sync_freq. The higher this value, the fewer the chances to go to sync_freq.
v) up_threshold_multi_core - When the up_threshold_multi_core is crossed, the cpu is ramped up to optimal_freq.
vi) optimal_freq - When more than one CPU is online and if up_threshold_multi_core has exceeded, the governor will ramp up the CPU to this frequency. This value should be less than your device's max CPU frequency.
Click to expand...
Click to collapse
6. Wheatley
[ PARAMETERS ]
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Click to expand...
Click to collapse
7. Darkness/Nightmare
[ PARAMETERS ]
cpu_up_rate - No of samples to evaluate load to scale CPU frequency up. Increasing this value will increase the time spent on a frequency.
cpu_down_rate - No of samples to evaluate load to scale CPU frequency down. Increasing this value will increase the time spent on a frequency
inc_cpu_load_at_min_freq - This threshold is used as up threshold while sampling at frequencies is less than freq_for_responsiveness.
inc_cpu_load - The frequency at which governor scales CPU up.
dec_cpu_load - The frequency at which governor scales CPU down.
Click to expand...
Click to collapse
8. zzmoove
[ PARAMETERS ]
sampling_rate_sleep_multiplier -> sampling rate multiplier on early suspend (possible values 1 or 2, default: 2)
up_threshold_sleep -> up threshold on early suspend (possible range from above 'down_threshold_sleep' up to 100, default: 90)
down_threshold_sleep -> down threshold on early suspend (possible range from 11 to 'under up_threshold_sleep', default: 44)
smooth_up -> smooth up scaling when screen is on (possible range from 1 to 100, default: 100)
smooth_up_sleep -> smooth up scaling on early suspend (possible range from 1 to 100, default: 100)
up_threshold_hotplug x -> hotplug threshold for cpu core x (0 disable core, possible range from 'down_threshold' up to 100, default: 68)
down_threshold_hotplug x -> hotplug threshold for cpu core x (possible range from 1 to under 'up_threshold', default: 55)
block_down_multiplier_hotplug x -> block down multiplier for core x
block_up_multiplier_hotplug x -> block up multiplier for core x
sampling_down_max_momentum -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)
sampling_down_momentum_sensitivity -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)
sampling_down_factor -> depending on which mode is active the factor for sampling rate multiplier which influences the whole sampling rate or the value for stock 'down skip' functionality which influences only the down scaling mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)
freq_limit_sleep-> limit freqency at early suspend (possible values 0 disable limit, 200-1600, default: 0)
freq_limit -> limit freqency at awake (possible values 0 disable limit, 200-1600, default: 0)
scaling_proportional -> if enabled load-proportional frequencies will be calculated in parallel and will be used in decision for next freq step. after a comparison between normal system table step and proportional step the lowest of these two frequencies will be used for next freq step in both directions. (0 to disable, any value above 0 to enable)
scaling_block_temp -> CPU temperature threshold from where governors freq 'holding' should start. if the given temperature (if CPU temp reading is enabled) is reached the frequency used in tunable 'scaling_block_freq' will be forced targeted and scaling stays on this freq till the temperature is under the threshold again. at the same time hotplugging up work is blocked so in this throttling phase offline cores are staying offline even if the hotplug up thresholds are reached (0 to disable, values between 30 and 80 in °C)
scaling_up_block_cycles -> similar to scaling fastdown but here for a slowdown of up scaling
scaling_up_block_freq -> similar to scaling fastdown but here for a slowdown of up scaling
fast_scaling_up -> Number of scaling jumps only for upscaling when screen on (skip 0-4 frequency steps) or 5 to use autoscaling.
fast_scaling_down -> Number of scaling jumps only for downscaling when screen on (skip 0-4 frequency steps) or 5 to use autoscaling.
fast_scaling_sleep_up -> Number of scaling jumps only for upscaling when screen off (skip 0-4 frequency steps) or 5 to use autoscaling.
fast_scaling_sleep_down -> Number of scaling jumps only for downscaling when screen off (skip 0-4 frequency steps) or 5 to use autoscaling.
disable_hotplug -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to enable it, default 0)
auto_adjust_freq_thresholds -> if enabled all freq thresholds used by the governor will be adjusted accordingly to the new scaling max policy. in particular the thresholds will be increased/decreased by the actual changed max freq step if that change will undercut/exceed the actual min/max freq policy it will stop at the max possible frequency step before undercutting/exceeding min/max freq policy (0 to disable, any value above 0 to enable)
early_demand -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)
grad_up_threshold -> scale up frequency if the load goes up in one step of grad up value (possible range from 1 to 100, default 50) little example for understanding: when the load rises up in one big 50% step then the frequency will be scaled up immediately instead of wating till up_threshold is reached.
early_demand_sleep -> same function as early demand on awake but in addition combined with fast scaling and sampling rate switch and only active at sleep. (possible values 0 disable or 1 enable, default is 1)
grad_up_threshold_sleep -> 2 way functionality: early demand sleep grad up (load gradient) threshold and at the same time load threshold for switching internally (tuneables are staying at set values!) sampling_rate_sleep_multiplier to 2 and fast_scaling to 2 (possible values from 1 to 100, default is 35)
hotplug_block_up_cycles -> (replaces hotplug_block_cycles) slow down up hotplugging by waiting a given amount of cycles before plugging. possible values 0 disable, any values above 0 (default is 0)
hotplug_block_down_cycles -> (replaces hotplug_block_cycles) slow down down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
hotplug_idle_freq -> freq at which the idle should be active (possible values 0 disable and any possible scaling freq, default is 0)
sampling_rate_current -> read only and shows currently active sampling rate
sampling_rate_idle -> sampling rate which should be used at 'idle times' (possible values are any sampling rate > 'min_sampling_rate', 0 to disable whole function, default is 0)
sampling_rate_idle_delay -> delay in cycles for switching from idle to normal sampling rate and vice versa (possible values are any value and 0 to disable delay, default is 0)
sampling_rate_idle_threshold -> threshold under which idle sampling rate should be active (possible values 1 to 100, 0 to disable function, default is 0)
scaling_block_cycles -> amount of gradients which should be counted (if block threshold is set) and at the same time up scaling should be blocked and after that a forced down scaling should happen (possible values are any value, 0 to disable that function, default is 0)
scaling_block_freq -> frequency at and above the blocking should be active (possible values are any possible scaling freq, 0 to enable blocking permanently at every frequency, default is 0)
scaling_block_threshold -> gradient (min value) of load in both directions (up/down) to count-up cycles (possible value are 1 to 100, 0 to disable gradient counting)
scaling_block_force_down -> multiplier for the maximal amount of forced down scaling cycles (force down cycles = block_cycles * force_down) therefore the forced down scaling duration (possible value are 2 to any value, 0 to disable forced down scaling and use only scaling up blocks)
profile_number ->
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
11) for ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)
scaling_fastdown_freq -> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)
scaling_fastdown_up_threshold -> once the above frequency threshold has been met, this will become the new up_threshold until we fall below the scaling_fastdown_freq again. (range from over fastdown_down_threshold to 100, default is 95)
scaling_fastdown_down_threshold -> once the above frequency threshold has been met, this will become the new down_threshold until we fall below the scaling_fastdown_freq again. (range from 11 to under fastdown_up_threshold, default is 90)
scaling_responsiveness_freq -> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)
scaling_responsiveness_up_threshold -> the up_threshold that will take effect if scaling_responsiveness_freq is set (range from 11 to 100, default is 30)
hotplug_engage_freq -> will not bring any cores online until this frequency is met or exceeded
(0 to disable, all possible system frequencies, default is 0)
music_max_freq -> maximum frequency for CPU when governor is on music mode
music_min_cores -> minimum CPU cores used when governor is on music mode
music_min_freq -> minimum frequency for CPU when governor is on music mode
afs_threshold 1,2,3 -> Auto fast scaling for step one to three respectively (range from 1 to 100)
Click to expand...
Click to collapse
9. Smartmax/Performance May Cry
[ PARAMETERS ]
boost_duration - how long you want the governor to boost your CPU in seconds.
down_rate - The minimum amount of time in nsecs to spend at a frequency before we can ramp down. Notice we ignore this when we are above the ideal frequency.
io_is_busy - Consider if IO is busy
max_cpu_load - CPU freq will be increased if measured load > max_cpu_load
min_cpu_load - CPU freq will be decreased if measured load < min_cpu_load
ramp_up_during_boost - should ramp_up steps during boost be possible
ramp_up_step - Frequency delta when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal freqeuncy we always ramp up to the ideal freq.
Touch_poke_freq - Also known as the touch boost frequency. This is the frequency that you CPU jumps to when touching screen.
Click to expand...
Click to collapse
I/O scheduler tuning guide
Deadline and SIO:
[ PARAMETERS ]
fifo_batch: This parameter controls the maximum number of requests per batch.It tunes the balance between per-request latency and aggregate throughput. When low latency is the primary concern, smaller is better (where a value of 1 yields first-come first-served behavior). Increasing fifo_batch generally improves throughput, at the cost of latency variation. The default is 16.
front_merges: A request that enters the scheduler is possibly contiguous to a request that is already on the queue. Either it fits in the back of that request, or it fits at the front. Hence it’s called either a back merge candidate or a front merge candidate. Typically back merges are much more common than front merges. You can set this tunable to 0 if you know your workload will never generate front merges. Otherwise leave it at its default value 1.
read_expire: In all 3 schedulers, there is some form of deadline to service each Read Request. The focus is read latencies. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of milliseconds. The default value is 500 ms.
write_expire: Similar to Read_Expire, this applies only to the Write Requests. The default value is 5000 ms.
writes_starved: Typically more attention is given to the Read requests over write requests. But this can’t go on forever. So after the expiry of this value, some of the pending write requests get the same priority as the Reads. Default value is 1.
This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
Click to expand...
Click to collapse
Noop:
[ PARAMETERS ]
add_random
In some cases, the overhead of I/O events contributing to the entropy pool for /dev/random is measurable. In such cases, it may be desirable to set this value to 0.
nomerges
This tunable is primarily a debugging aid. Most workloads benefit from request merging (even on faster storage such as SSDs). In some cases, however, it is desirable to disable merging, such as when you want to see how many IOPS a storage back-end can process without disabling read-ahead or performing random I/O.
nr_requests
If you have a latency-sensitive application, then you should consider lowering the value of nr_requests in your request queue and limiting the command queue depth on the storage to a low number (even as low as 1), so that writeback I/O cannot allocate all of the available request descriptors and fill up the device queue with write I/O. Once nr_requests have been allocated, all other processes attempting to perform I/O will be put to sleep to wait for requests to become available. This makes things more fair, as the requests are then distributed in a round-robin fashion (instead of letting one process consume them all in rapid succession).
optimal_io_size
In some circumstances, the underlying storage will report an optimal I/O size. This is most common in hardware and software RAID, where the optimal I/O size is the stripe size. If this value is reported, applications should issue I/O aligned to and in multiples of the optimal I/O size whenever possible.
rotational
Traditional hard disks have been rotational (made up of spinning platters). SSDs, however, are not. Most SSDs will advertise this properly. If, however, you come across a device that does not advertise this flag properly, it may be necessary to set rotational to 0 manually; when rotational is disabled, the I/O elevator does not use logic that is meant to reduce seeks, since there is little penalty for seek operations on non-rotational media.
rq_affinity
I/O completions can be processed on a different CPU from the one that issued the I/O. Setting rq_affinity to 1 causes the kernel to deliver completions to the CPU on which the I/O was issued. This can improve CPU data caching effectiveness.
Click to expand...
Click to collapse
CFQ:
[ PARAMETERS ]
back_seek_max: The scheduler tries to guess that the next request for access requires going backwards from current position on the Disc. Given that such going back can be time consuming. So in anticipation, may move back on the disc prior to the next request. This setting, given in Kb, determines the max distance to go back. Default value is set to 16 Kb.
Do note that in a cellphone or tablet, the storage is actually Flash Memory technology. There is Disk head to be re-positioned. As such this is not that effective as backward reads are not that bad.
back_seek_penalty: This parameter is used to compute the cost of backward seeking. If the backward distance of a request is just 1 from a front request, then the seeking cost of the two requests is considered equivalent and the scheduler will not bias toward one or the other. This parameter defaults to 2 so if the distance is only 1/2 of the forward distance, CFQ will consider the backward request to be close enough to the current head location to be “close”. Therefore it will consider it as a forward request.
fifo_expire_async & fifo_expire_sync : This particular parameter is used to set the timeout of asynchronous requests. CFQ maintains a fifo (first-in, first-out) list to manage timeout requests. The default value is 250 ms. A smaller value means the timeout is considered much more quickly than a larger value. Similarly, fifo_expire_sync applies to the Synchronous requests. The default is 125 ms.
group_idle: If this is set, CFQ will idle before executing the last process issuing I/O in a cgroup. This should be set to 1 along with using proportional weight I/O cgroups and setting slice_idle to 0 as Flash memory is a fast storage mechanism.
group_isolation: If set (to 1), there is a stronger isolation between groups at the expense of throughput. If disabled, Scheduler is biased towards sequential requests. When enabled group isolation provides balance for both sequential and random workloads. The default value is 0 (disabled).
low_latency: When set (to 1), CFQ attempts to build a backlog of write requests. It will give a maximum wait time of 300 ms for each process issuing I/O on a device. This offers fairness over throughput. When disabled (set to 0), it will ignore target latency, allowing each process in the system to get a full time slice. This is enabled by default.
Quantum: This option controls the maximum number of requests being processed at a time. The default value is 8. Increasing the value can improve performance; the latency of some I/O may be increased due to more requests being buffered inside the storage.
slice_async: This parameter controls Maximum number of asynchronous requests at a time. The default value is set to 40 ms.
slice_idle: When a task has no more requests to submit in its time slice, the scheduler waits for a while before scheduling the next thread to improve locality. The default value is 0 indicating no idling. However, a zero value increases the overall number of seeks. Hence a Non-zero number may be beneficial.
slice_sync: This setting determines the time slice allotted to a process I/O. The default is 100 ms.
Click to expand...
Click to collapse
BFQ:
[ PARAMETERS ]
timeout_sync & timeout_async: These parameters determine maximum disk time given to a task, respectively for synchronous and asynchronous queues. It allows the user to control the latencies imposed by the scheduler.
max_budget: This determines, how much of the queue request is serviced based on number of sectors on disc. A larger value increases the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. Consequence is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning
max_budget_async_rq: This setting determines number of async queues served for a maximum number of requests, before selecting a new queue.
low_latency: When this is set to 1 (default is 1), interactive and soft real-time applications experience a lower latency.
Click to expand...
Click to collapse
ROW:
[ PARAMETERS ]
hp_read_quantum: Dispatch quantum for the high priority READ queue. Default: 10
rp_read_quantum: Dispatch quantum for the regular priority READ queue. Default: 100
hp_swrite_quantum: Dispatch quantum for the high priority Synchronous WRITE queue. Default: 1
rp_swrite_quantum: Dispatch quantum for the regular priority Synchronous WRITE queue. Default: 1
rp_write_quantum: Dispatch quantum for the regular priority WRITE queue. Default: 1
lp_read_quantum: Dispatch quantum for the low priority READ queue. Default: 1
lp_swrite_quantum: Dispatch quantum for the low priority Synchronous WRITE queue. Default: 1
read_idle: Determines length of idle on read queue in Msec (in case idling is enabled on that queue). Default: 5ms
read_idle_freq: Determines the frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests. Default: 5ms
Click to expand...
Click to collapse
VR and Zen:
[ PARAMETERS ]
rev_penalty: Penalty for reversing head direction.
fifo_batch: Number of requests to issue before checking for expired requests.
sync_expire: Deadline for synchronous requests.
async_expire: Deadline for asynchronous requests.
Click to expand...
Click to collapse
Hotplug tunables guide
NOTE: If you don't have some of these tunables, you might have an older version of the hotplug driver and/or the kernel maintainer has made modifications to it.
Mako Hotplug:
[ PARAMETERS ]
load_threshold: system load threshold to decide when online or offline cores from 0 to 100
high_load_counter: counter to filter online/offline calls. The load needs to be above load_threshold X high_load_counter times for the cores to go online otherwise they stay offline
max_load_counter: max number of samples counters allowed to be counted. The higher thevalue the longer it will take the driver to offline cores after a period of high and continuous load
cpufreq_unplug_limit: if the current CPU freq is above this limit don't offline the cores for a couple of extra samples
min_time_cpu_online: minimum time in seconds that a core stays online to avoid too many online/offline calls
int timer: sample timer in seconds. The default value of 1 equals to 10 samples every second. The higher the value the less samples per second it runs
Click to expand...
Click to collapse
msm_mpdecision/bricked hotplug
[ PARAMETERS ]
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (70)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1.
max_cpus = max cpus to be online (if you set it to 2 and min_cpus to 1 you will basically have a dualcore)
idle_freq = a value against that will be checked if a core +/- is requested.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
Click to expand...
Click to collapse
AutoSMP
[ PARAMETERS ]
max_cpus, min_cpus, scroff_single_core, delay: Look at description above
enabled: Enable/Disable AutoSMP. Y ( for enabled). N (for disabled)
cpufreq_down: Percentage values for downrate limit (range from 0 - 100)
cpufreq_up: Percentage values for uprate limits (range from 0 - 100)
cycle_down: Cycles to wait after the last hotplug event to unplug another core (values 0 1 2 3 4)
cycle_up: Cycles to wait after the last hotplug event to plug another core (values 0 1 2 3 4)
Click to expand...
Click to collapse
Alucard
(sourced from defconoi's kernel guide)
[ PARAMETERS ]
hotplug_sampling_rate:
Sampling Interval, measured in ms. This factor determines how often the governor should poll for CPU usage in terms of frequency and load percentage to make hotplugging decisions. (Default: 30 ms)
hotplug_rate_x_1:
Number of samples to evaluate cpu x hotplug in, where x is greater than or equal to 1.
hotplug_rate_(x+1)_0:
Number of samples to evaluate cpu x hotplug out
hotplug_freq_x_1:
Up threshold frequency to turn core x On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq x 1) Hotplug IN Second Core. Higher value corresponds to delay in turning on second core.
hotplug_freq_(x+1)_0:
Down threshold frequency to turn core x Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq (x+1) 0) Hotplug OUT Second Core. Lower value corresponds to delay in turning off second core.
hotplug_load_x_1:
The CPU load at which governor scales CPU up. Current Load equal or greater than up_load: CPU Hotplug IN. Value corresponding to 101 causes not HOTPLUG IN.
hotplug_load_(x+1)_0:
The CPU load at which governor scales CPU down. Current Load less than down_load and CPU online greater than 1: CPU Hotplug OUT. Value corresponding to 101 causes immediately HOTPLUG OUT.
hotplug_rq_x_1:
Threshold run queue length for core x to turn on. (Default: 100)
hotplug_rq_(x+1)_0:
Threshold run queue length for core x to turn off. (Default: 100)
maxcoreslimit:
Max CPU's hotplugging limit.
maxcoreslimit_sleep:
Max CPU's hotplugging limit.
Click to expand...
Click to collapse
TCP algorithms guide
What are TCP algorithms?
Congestion control strategies (or algorithms) are used by TCP, the data transmission protocol used by many Internet applications. The main goal of a TCP algorithm is to avoid sending more data than the network is capable of transmitting, that is, to avoid causing network congestion. Different algorithms respond differently to network loads, but they are all based on the same principle of avoiding network congestion.
Things to look out for in TCP algorithms include (but not exclusively):
- Download/Upload speeds - The higher the number, the better
- Latency - The lower the number, the better
TCP Algorithm Descriptions
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Click to expand...
Click to collapse
Reno:
Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.
Click to expand...
Click to collapse
Vegas:
One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Click to expand...
Click to collapse
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
Click to expand...
Click to collapse
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Click to expand...
Click to collapse
Westwood/Westwood+:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
Click to expand...
Click to collapse
Low Priority (LP):
A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.
Click to expand...
Click to collapse
Binary Increase Congestion control (BIC):
BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.
Click to expand...
Click to collapse
Scalable:
Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up.
Click to expand...
Click to collapse
Hamilton TCP (HTCP):
HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP.
Click to expand...
Click to collapse
Veno:
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
Click to expand...
Click to collapse
Illinois:
Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.
Click to expand...
Click to collapse
High speed (HSTCP):
High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.
Click to expand...
Click to collapse
Yeah-TCP:
A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.
Click to expand...
Click to collapse
CDG
CAIA-Delay Gradient (CDG) is a new hybrid congestion control algorithm which reacts to both packet loss and queuing delay. It attempts to operate as a delay-based algorithm where possible, but detects loss-based TCP traffic and will switch if required. CDG performs similarly to NewReno and Cubic, but is better at latency.
Click to expand...
Click to collapse
Benchmark
Results:
Latency - Download - Upload
cubic:
1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps
reno:
1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps
bic:
1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps
westwood:
1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps
highspeed:
1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps
hybla:
1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps
htcp:
1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps
vegas:
1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps
veno:
1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps
scalable:
1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps
lp:
1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps
yeah:
1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps
illinois:
1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps
Recommendations:
For speed:
- Westwood - Best
- Highspeed
- LP
For stability:
- Cubic - Best
- Reno
For high latency networks:
- Westwood - Best
- BIC
For general usage:
- Cubic - Best
- Westwood - Best
- Reno
Conclusion:
The only TCP algorithms I would recommend are Cubic or Westwood as they are the most stable and efficient for mobile devices. Real world usage would show little difference when comparing between algorithms, so everyone's experience will vary! There are myths that changing algorithms will affect battery life, this is not true!!!!!
Also, don't be surprised if you end up using Cubic or Westwood!
Conditions of use
Before everyone starts to copy all of my information I've provided in this guide, please note that I've spend countless hours collecting and refining all of the descriptions and details found from various other guides and comments around the net. I'm not too fussed if people forget to mention credits, but straight copy and pasting the whole guide (verbatim) is what I'm "not OK with". Its not like I can license this information anyway or forcefully prevent others from doing this, but keep this in mind anyway
Remember that this info is for free and can be used for your own help and for others if you follow XDA rules and under my conditions!
Changelog:
Code:
10/09/19:
- Added CPU governor section headings (HMP and EAS)
- Added Multi-queue I/O scheduler section
05/02/19:
- Added Anxiety IO scheduler
- Added pwrutilx and blu_schedutil
19/06/18:
- Added improved CPU governor recommendations
18/06/18:
- Updated I/O scheduler recommendations
29/05/18:
- Added description for Cultivation CPU governor
- Added missing governors from governor list on the OP
27/02/18:
- Removed governor summaries
- Adapted the hotplug and GPU governor layout to be the same as the CPU governor layout (no more one liners)
- Added info on the thenewbeginning governor
19/12/17:
- Added lazyplug description
- Added crazyactive governor description
- Removed hotplug recommendations (outdated, inaccurate)
01/12/17:
- Minor additions to I/O scheduler advantages/disadvantages breakdown
- Minor rewording of I/O scheduler summaries
24/11/17:
- Cleaned up the starting paragraphs of the OP (Shortened but also gets the same message that I want)
16/07/17:
- Removed multi-core CPU governor selection guide
- Added EAS governor section
- Simplified I/O scheduler benefits and disadvantages. Removed non-relevant information, added some new ones as well.
15/07/17:
- Removed "what to look out for" sections
- Removed kernel app recommendations
- Removed governor classifications
- Removed generic looking IO sched and TCP alg comparisons - Non-realistic and variable, YMMV
- Made the CPU hotplug guide simpler and easier to read. Updated with better recommendations
- Moved zzmoove profile number info into CPU gov tunable section
- Added a new summary section under all CPU governors to help give a basic comparison between governors - Don't take these indicators as your only deciding factor, ask around as well before using!
29/05/17:
- Remove sig from main posts
- Added precaution to recommended governor guide
12/03/17:
- Removed some governors from recommended list
8/03/17:
- Added descriptions for Nebula and Relaxed CPU governors
1/03/17:
- Minor update to Mako hotplug description
- Updated description for Ktoonservative
25/02/17:
- Updated description on mako hotplug
24/02/17:
- Updated multi-core CPU governor selection guide as per website changes
19/12/16:
- Changed recommended I/O read-ahead buffer values for 32GB+ to a more sensible value
26/11/16:
- Updated summaries for I/O schedulers
23/11/16:
- Updated ElementalX CPU governor description
22/11/16:
- Improved 'what to look out for' sections for the CPU governor and I/O scheduler guide
14/11/16:
- Added ZZmoove native hotplug description
- Fixed sprdemand governor description
15/10/16:
- Huge cleanup to the formatting of this guide. Headings now have bigger font size, excessive bold use removed, minor fixes everywhere else
14/10/16:
- Updated interactive tuning guide with additional tunable information
13/10/16:
- Added Ironactive CPU governor description
10/10/16:
- Added Kraken CPU governor description
29/08/16:
- Small correction to 8GB internal/external storage recommended I/O read ahead value
28/09/16:
- Updated guide on I/O read ahead buffer
13/09/16:
- Corrected 'ondemand' GPU governor name to 'simple_ondemand'
11/09/16:
- Added more detailed and accurate descriptions of existing GPU governors. More GPU governor descriptions will be added later.
10/09/16:
- Minor fixes to ZEN I/O scheduler description
- Added ZEN v2 I/O scheduler description
- Minor update to recommended I/O scheduler list
- Added very detailed description of Maple I/O scheduler thanks to @frap129
- Remove Anticipatory I/O scheduler description
- Updated credits list. Added new credits where applicable.
02/09/16:
- Added sprdemand governor description
20/08/16:
- Added Maple I/O scheduler description
- Minor modifications to I/O scheduler summaries
19/08/16:
- Added general comments on each scheduler
- Small cleanup to scheduler descriptions
14/08/16:
- Added State Helper hotplug information
30/07/16:
- Updated list of recommended apps. Removed all paid options
27/07/16:
- Added Chill CPU governor description
- Added Hima hotplug description
15/07/16:
- Updated description for Cyan governor
14/07/16:
- Added Intel, Frankenstein, TheSSJactive and Cyan governor descriptions
13/07/16:
- Added sched-DVFS governor description
23/03/16:
- Updated recommended CPU governors, removed rating system, combined single-core and multi-core recommended governors into general lists
- Updated recommended I/O schedulers, a few cosmetic fixes
- Simplified CDG TCP algorithm description
- Added Fast hotplug description
14/06/16:
- Cleanup to I/O scheduler descriptions. Removed battery factors from advantages.
11/06/16:
- Added ThunderX CPU governor description
07/06/16:
- Added information about cpuquiet
30/05/16:
- Initial reorganization of content - Tuning guides have been separated and will soon include examples of profiles
- I/O tuning guide is back!
- Initial guide for TCP algorithms
- More to come soon ;)
21/05/16:
- Many updated tunable descriptions for interactive, ondemand and conservative cpu governors (sourced from the generic android kernel documentation)
- Removed I/O scheduler tuning guide (look at my website link instead)
- Minor changes to zzmoove tunable descriptions
07/05/16:
- Added description for lightning governor, thunderplug hotplug and blu_plug hotplug
06/04/16:
- Added a bit of info on some tunables for Alucard hotplug. Due to space limitations, you must use my website for the rest of the info.
- Some tunable info was removed either because it was too long (now it would be simplified) or was not used.
01/04/16:
- Added Cafactive governor description
12/03/16:
- Added interextrem governor description
09/01/16:
- Added descriptions for Despair, Electroactive, Electrodemand and Lionfish CPU governors
13/12/15:
- Fixed up ElementalX cpu governor description (was totally wrong before)
09/12/15:
- Added HyperX CPU governor description
26/11/15:
- Added more info about smartmax and Dyninteractive CPU governor
15/11/15:
- Many changes to existing CPU governor descriptions. A lot of irrelevant statements removed
10/11/15:
- Added yankdemand CPU governor description
- Fixed credits for intelliplug hotplug
09/11/15:
- Added hotplug tunable guide for mako hotplug, msm_mpdecision, bricked hotplug and AutoSMP
- Lots of cleanup to tunable post. All irrelevant information deleted! Now there is more room for more tunable explanations!
- Removed all irrelevant messages in OP. I think it is pretty self-explanatory to use this guide.
- Added AutoSMP hotplug description from mrg666
01/11/15:
- Many changes to IO scheduler information. Most spelling mistakes and incomplete sentences should be fixed now. I removed irrelevant information on some schedulers.
22/10/15:
- Added description for PegasusQPlus CPU governor
16/10/15:
- Recommended apps sections improved now with more details on what is free and what is a paid feature
- Recommended apps added to tuning section
- Added more zzmoove variable explanations
06/10/15:
- Updated recommended apps to change CPU governors and IO schedulers
25/09/15:
- Multiple changes to recommended CPU governors
24/09/15:
- Added a few GPU governor descriptions
21/09/15:
- Added information about Mythx_plug CPU governor and msm_sleeper hotplug driver
19/09/15:
- Added tunable info for VR io scheduler
- Fixed up Zen io scheduler tunable info (now with VR)
- Updated I/O read ahead section to match with website (Recommendations, rearrange layout)
18/09/15:
- Removed sample tweaks to CPU governors
- Added a huge list of zzmoove tunables
- Updated Smartmax tunable info
24/08/15:
- Added descriptions for new governors (Arteractive and Precognition)
23/08/15:
- Added Adreno Idler GPU governor description
- Bolded GPU governor names
08/08/15:
- As requested, I've updated the recommended CPU governors
01/08/15:
- Added Barry-Allen CPU governor description
21/07/15:
- Multiple changes to hotplug section
- Added a new zzmoove profile descriptions
- Fixed spelling mistake with zzmoove (it is NOT zzmove!)
09/07/15:
- Added 1 CPU governor description (Wave)
01/07/15:
- Added more hotplug driver descriptions and improved existing hotplug descriptions
26/05/15:
- Added Nightmare/Darkness CPU governor tunable descriptions
- Cleanup to tunable samples
23/05/15:
- More updates to I/O scheduler descriptions
22/05/15:
- Most I/O scheduler descriptions have been updated
16/05/15:
- Cleanup to recommended CPU governors
- Cleanup of I/O scheduler recommendations
- Bolded CPU governor names (finally!!!!)
15/05/15:
- Fixed misleading information on blu_active governor (Thanks the eng.stk for providing some clarification!)
- Updated a few other CPU governor descriptions
13/05/15:
- Cleanup to summary of sections in the posts
09/05/15:
- Added a guide for things to look at in CPU governors and I/O schedulers
11/04/15:
- Added a few new CPU governor descriptions
- Minor changes to recommended CPU governors
09/04/15:
- Added more information on I/O schedulers
- Added a CPU governor
- Added test IO scheduler
07/04/15:
- Multiple changes to I/O scheduler advantages and disadvantages
- Links to apps now working now
03/04/15:
- Multiple changes to CPU governor descriptions
26/03/15:
- Small cleanup to CPU governor names
- Added a CPU governor description
- Small changes to CPU governor descriptions
- Updates to I/O scheduler descriptions
21/03/15:
- Cleanup of CPU governor descriptions
- General fixes to layout for CPU governor hotplugging descriptions
20/03/15:
- Added guide to mixed CPU governor arrangements
15/03/15:
- Added some CPU governors
- Updated tweaks guide with some tweak examples of I/O scheduler (sorry for the late change)
- Updated CPU benchmark graphs (Once again, thanks to haldi)
14/03/15:
- Cleanup and updates to recommended CPU governors
Things to do:
Code:
- Revamp CPU governor guide so it is easier to find governor tweaks (possible with the use of linking) - Shouldn't be too hard
- Update recommendation guides for CPU govs and I/O schedulers so they are more informative, while also having a section for people who can't decide :)
- Links to governor/IO source code for potential help to kernel developers - Some effort required IMO, possibly not worth doing as it is beyond the scope of this guide
- Group governor description according to their scaling behaviour (e.g. Ondemand-like, conservative-like, etc.) - Will take time, but I will see
- More that I forgot, but these are the ones that came from the top of my head
- Why don't you ask for me to add something new! :)
FAQ
Q: Why doesn't my kernel has XYZ governor/scheduler/feature?
A: I wouldn't have a clue. Ask your kernel maintainer. They haven't added it yet or maybe they don't plan on doing so.
Q: I've found similar guides on the net with almost or exactly the same wording, who should I trust?
A: This guide along with my blogger website are the only official guides that should only have this information.
Q: Why are you ripping off other peoples guides?
A: Credits are given where due as detailed in the credits list below.
Q: Can you please add XYZ governor/scheduler/feature to your guide?
A: Sure. Either post in this forum (ehm, please don't quote the whole OP), or throw me a PM.
Q: Man. Your formatting sucks? When will you fix it?
A: Coming soon tm... Kidding, I'm still working on it
The credits list:
Stempox - Most old cpu governor descriptions was sourced from his guide
Droidphile - Basically the one of the first people to start these guides. Template for tweak guides.
Haldi - Without haldi, there wouldn't be these awesome graphs
Matmutant(Andrux&me) - For his I/O scheduler guides and graphs
Perseus - For several I/O scheduler tweak guides
franciscofranco - For TCP algorithm benchmarks
And all of the other XDA members and other people who came up with some other descriptions that haven't been mentioned.
Thank you for this!
This is a much-needed (and much-asked!) document for many people
can you post some info on governor tuning? specifically ROW... like what all the options are that are available and what they do, and recommended settings?
Amazing man !
This should be very useful to everyone here on the forum
Found this informations on a google search yesterday on your site, and i saw alot of it is copied from other places on the net like :
Code:
http://androidforums.com/threads/android-cpu-governors-explained.513426/
and :
Code:
http://forum.xda-developers.com/showthread.php?t=1736168
another :
Code:
http://forum.xda-developers.com/showthread.php?t=1631894
But alot of updated info and i thank you alot for that :good:
But normaly dont we need a source list and a thank you on XDA like links? when something posted that you did not write 100% your self?
Thanks
Thanks this is very useful for me.
In Cm12, the I/o schedule menu contains an item called "test-iosched" alongside noop, deadline etc, what does that mean?
Thank You Much
I know i personally was looking for a "all explained" document and this is it! your time in making this is appreciated!
Awesoe thread, kind of a encyclopedia of governors etc.!
Very nice job!
i have a nexus 4 with android 5.0.1 matr1x kernel 14.5 my setups are:
1,5ghz interactive
and cfq
is this a good combination? whats the better combination for battery life? for performance?
Hi,
I'm using hellsdoctor kernel for the nexus 4, and i have a hellsactive Governor.
Would like to know about that Governor.
Thanks!
Ragingmolasses is a governor that recently seems to enjoy some popularity. Perhaps it could be included?
Thanks
Very excellent
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 for the Xperia M2
NOTE:not all govenors listed will be available for every rom or every kernel
1) Ondemand
2) Interactive
3) Intellidemand
4) Userspace
5) Powersave
6) Performance
1) Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.
2) Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why?????Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.
3) 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) by behaving like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
4) 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.
5) Powersave
Powersave governor locks the CPU frequency at the lowest frequency set by the user.Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
6) Performance
The performance governor locks the phone's CPU at maximum frequency(Used for benchmarking)
GOVERNOR TWEAKS
PARAMETERS & TWEAKS:
1.ONDEMAND
[ PARAMETERS ]
i) sampling_rate - Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
ii) up_threshold - Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
iii) powersave_bias - Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
iv) sampling_down_factor - In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
v) down_differential - This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
vi) freq_step - Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step
percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.
[ SAMPLE TWEAKS ]
i) For battery:-
To bias ondemand towards battery saving, set high up-thresholds and higher sampling-rate. This way, governor polls less often and scales up less often.
up_threshold : 95
sampling_rate : 120000
sampling_down_factor : 1
down_differential : 5
ii) For performance:-
To bias ondemand towards performance, set low up-thresholds and lower sampling-rate. This way, governor polls more often and scales up quite often.
up_threshold : 70
sampling_rate : 50000
sampling_down_factor : 2
down_differential : 15
2.INTERACTIVE
[ PARAMETERS ]
i) hispeed_freq - Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
ii) go_hispeed_load - Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
iii) min_sample_time - The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
iv) timer_rate - The sample rate of the timer used to increase frequency.
[ SAMPLE TWEAKS ]
i) For battery:-
go_hispeed_load : 95
hispeed_freq : 1000000
min_sample_time : 10000
timer_rate : 40000
For performance:-
Assuming your scaling_max_freq is equal to or above 1400 MHz
go_hispeed_load : 80
hispeed_freq : 1400000
min_sample_time : 40000
timer_rate : 20000
Additional Info:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hotplugging drivers:
mpdecision: Qualcomm's default hotplugging driver. One of the most widely used hotplug drivers in all android devices.
msm_hotplug: Great battery life, a custom qualcomm based hotplugging driver by myflux. It is a popular choice for many users.
intelliplug: Great balance between battery life and performance. It is also a popular hotplug driver from faux123
Hotplug tunables guide
1) msm_mpdecision
[ PARAMETERS ]
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (70)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1.
max_cpus = max cpus to be online (if you set it to 2 and min_cpus to 1 you will basically have a dualcore)
idle_freq = a value against that will be checked if a core +/- is requested.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
I/O Schedulers:
Available I/O Schedulers for the Xperia M2:
1.Deadline
2.Noop
3.SIO (Simple I/O)
4.ROW
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:
- 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, most likely the best
- Like noop, a good scheduler for solid state/flash drives
Disadvantages:
- If the phone is overloaded, crashing or unexpected closure of processes can occur
The bottom line: A good all-round scheduler. If you want good performance
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.
- Best for flash drives since there is no seeking penalty.
- Good data throughput on db systems
- Does great in benchmarks
- Is very reliable
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)
The bottom line: Modern smartphones now use noop as the default scheduler due to the fact that it works quite well with flash based storage. However older devices may experience slower performance when selected. If you want a very simple I/O scheduler algorithm (because of battery life or latency reasons).
SIO (Simple I/O):
Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between noop & deadline. No reordering or sorting of requests.
Benefits:
- It is simple and stable.
- Minimized starvation for inquiries
- Not the best scheduler for benchmarks
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
The bottom line: One of my favourite schedulers, it is a good all-round scheduler. People who want better performance should avoid using this.
ROW:
The ROW I/O 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 I/O 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
Disadvantages:
- Not great for heavy multitasking
- Slower write speeds
The bottom line: Most phones will get a nice I/O boost, however experience varies between devices.
I/O Read Ahead Cache :
If you've used a custom kernel, you probably have heard of a term called Read Ahead cache or size. It's basically a cache for files that have been opened recently on your mobile device, so that they can be quickly accessed again if needed. By android default, this value has been set to 128kB. Usually having more cache means that more files can be cached, this can mean higher read and write speeds, but also this can result in more i/o latency. There is a point where increasing the I/O read ahead will have no benefit to read/write speeds.
Have a look at the graph below:
Recommendations:
For stability:
Use 128kB read-head value
For performance:
Use 2048kB read-head value
For any internal storage:
Use 128kB read-ahead value
For external SD cards with less than 8GB:
Use 128kB read-head value
For 16GB external SD cards:
Use 1024kB read-head value
For 32GB external SD cards:
Use 2048kB read-head value
For 64GB+ external SD cards:
Use 2048kB read-head value
What to remember:
- More isn't always better!
- Some SD cards can't handle high read ahead cache values, so make sure you have a genuine high quality SD card
- Default is good enough for most people, but isn't the best for performance
- Not all kernels allow users to change the I/O read ahead
- Performance difference varies between devices
In simple, a 1024kB read ahead should suit most devices today. 2048kB and 512kB are also good options I recommend too.
GPU Governors
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. It is still a balanced governor for everyday usage.
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. This is a widely used governor in qualcomm devices.
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.
I have spent many hours compiling all of the info on CPU governors and I/O schedulers.If you want to use the descriptions and info in your own thread, make sure to give me credit for gathering this info and also mention the others for their descriptions too. Remember that this info is for free and can be used for your own help and for others if you follow XDA rules
https://www.youtube.com/user/UmeshCahill
Thanks for the post, really interesting :good:
wow, that's really awesome sir . Nice info
iFlashed said:
Thanks for the post, really interesting :good:
Click to expand...
Click to collapse
You are welcome
FunSucker said:
wow, that's really awesome sir . Nice info
Click to expand...
Click to collapse
Thanks. Also..tested it on many ROMs...made XPERIA m2 cm12.1 beta 2 possible for daily usage..no lags/freezes
Umesh1041 said:
Thanks. Also..tested it on many ROMs...made XPERIA m2 cm12.1 beta 2 possible for daily usage..no lags/freezes
Click to expand...
Click to collapse
Would be great If u could suggest these tweaks to ROM developers