Welcome to Smurf Land.......Where you are whisked away to a smurfalicious place!
LA LA lalalala LA LA LA LA LAAAAAA....
Alright enough with the cuteness of all this.
Basically I have created a script that prompts you (the user) to answer some vital information them based on your answers the script will inject specific tweaks to your build.prop and also to a file in your init.d folder. These tweaks include battery tweaks, memory tweaks, speed tweaks, governor tweaks, 3g and wifi tweaks, SD card tweaks, and a bunch of random tweaks. Some collected from a bunch of different phones tweaks and others created by me.
The script will search out every line in your build.prop and remove any line that is there that I am adding and remove it first to reduce duplicate codes. It will remove a whole list of other init.d files that conflict with it. Will also create a few other files and folders to add functionality and speed optimization to your phone.
What if you do not like the tweaks that I added.....well the script creates back-ups for you and you can choose the option to Un-Smurf and it will set you back to before you installed.
CREDITS
zeppelinrox for his excellent scripts.
tommytomatoe for answering all my ridiculous questions and also the space in which to post my work
Lpy for his loopy smoothness
eoghan2t7 for his tutorial on loopy smoothness
knzo for his collection of tweaks
[email protected] for his collection of scripts which I pulled some tweaks from
metalspring for his explanation of a lot of tweaks and some build.prop and init.d tweaks
scottypeterson for his ultimatescript
cwc3 for his collection of scripts which I borrowed settings from
tazzz811 for his thread on some great init.d tweaks
droidphile for his incredible guides and some great governor tweaks and I/O scheduler tweaks
Each persons name has a link attached to it to show their work and threads which to thank them.
These Settings are all over the Internet across multiple forums and presented by more than a dozen people. If any setting in here was initially created by you and you did not get credit please PM me with your Info so I can add you to the credits. No work here has been stolen or taken on purpose. If you created or founded any of these setting and do not wish for me to use them then again please PM me and I will remove them as soon as possible. Please do not start a flame war on this thread due to my ignorance. I am just trying to get these settings out to as many people as possible to bring the smoothest experience to Our phones.
Instructions
1. Download Smurfed Out script.
2. Open up Script Manager found here if you don't have it
3. Scroll Down to the Smurfed_Out.sh file and click on it. This could Possible be in your downloads folder.
4. Click on the su key, the skull and crossbones, or run as root depending on which version of script manager you have then click run
5. Follow instructions on the screen.
!!! Warning !!!
By using this script you acknowledge that it could possible break your phone. In other words don't come running to me when you phone burst into flames and or it leaves you for someone as sexy as it has now become.
Download
{
"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"
}
Smurfed Out V 6.6
Other Phones
Please feel free to post a thread in other forums or other site but please link back to here for the downloads. I am trying to give the user the best experience possible and if dl links are made all over the place then there is possibility for them to not get updated when I release a new version. Plus the info in the first three post here explains alot.
Developers
If you would like this baked into your ROM the PM me and I can help. I already have a ZIP file created with he exact files that you need and instructions with how to implement. I need to make a few corrections based on your specific Rom but it is an easy fix and would rather do it or help you do it so there arnt any conflicts at all. I have already helped a few other DEV's bake it into their Roms and it works great.
Thank Me
If You Find this post USEFULL and ENJOY using the SMURFED OUT Script then Please take the time out to THANK ME. I'm Not asking for Donations but this does take countless hours to put together. Also you can click the links in my sig to see my working in the google market(PLAY) follow me on my Twitter and Facebook sites
Info
I/O Scheduler descriptions
Different Governors
LMK Settings (Low Memory Killer)/ADJ & MINFREE Values
ICS USERS
IF running ICS then go here to auto patch your SERVICE.JAR for new OOM settings.
FYI your services.jar can be found /system/frameworks/services.jar.
Seriously
If your coming from a version before 4.0 I Highly recommend Un-Smurfing First
Highly Recommended
If you want to make sure the settings stick....go into your /system/etc/init.d folder with script manager and set the 45smurfed file to run as root and run at boot. Some say this makes the setting stick others see no effect.
MUST READ
If your launcher does not show up in the auto detector then please inform me of the package name (found in /data/data) usually looks like this blah.blah.launcher. I will add it to the database and update the script rather quickly.
Change log
V 6.6
Added Instant Smurf-Power option which will clear out caches and give your phone an oh so fresh feeling (kinda like restarting your phone without having to)
Added in half a dozen build.prop tweaks
Fixed Some issues with the 45smurfed file
Added in ability to choose how much you want your Dalvik heapsize to be
Rearranged the Loopy Smoothness Tweak
Added in EXT4 Tweaks (convert your sd card over to ext4 and answer the question in the script for it to go into effect)
Added in swap support
Added in some new checks
Added in some permission sets so settings dont get overwritten
I'm sure there are more but can't think of any
Highly recommended that you UN-SMURF before you run the newest version as some of the files that the script removed in last version are needed in this version.
V 6.5.1
Fixed name of Launcher not being correct
Fixed wifi and 3g not switching, addition of last minute build.prop tweak jacked it all up
V 6.5
Fixed some syntax errors
Corrected names of a few launchers
Added in redundancies to back up everything the script removes so when unsmurfing there is no residual effects and everything is returned to Pre-Smurfed conditions
Everything is now backed up to a folder created on your SD card now instead of spread all over. File is called SmurfedBackups
Tried to fix Launcher Detector not reading some Launchers but cant get pm list packages to sent list to a file with out getting a segmentation error...any suggestions would be helpful
If your launcher is not found and you know the name of it try it out cause its saved in the detector as a launcher just isn't being autodetected
On AOKP and roms based off of it some of the init.d tweaks you find in rom control startup tweaks will not work anymore as i removed them becuase my script does it for you now. They will be restored if you Un-Smurf
Updated HTML doc with latest build.prop edits
Changed a few settings in build.prop
V 6.4
Fixed launchers not being found
Reorganized code
Added the google dns servers to the resolv.conf file
Added in check for HWA and if there it removes cpu rendering to speed up os
Fixed some syntax errors in init.d file
Added in a few new build.prop tweaks
Added in regroupings of OOM Settings into the build.prop
V 6.3
Added Miui Launcher
Added Lightning Launcher
Changed the way the I/O Schedule List shows up
Changed the defraging database process. Should be a lot cleaner now.
Added a few extra build.prop tweaks. If you look at them the values are
supposed to be blank.
V 6.2
Fixed problem with Cron files not copying over correctly
V 6.1
Fix syntax error
V 6.0
Added checks to make sure no typing error occur
Added info on which settings you are using to menu
Added more options to the menu that allows you to
Change your Launcher
Change your LMK Settings
Change your I/O Scheduler
Changed LMK settings names (Spaceballs Reference now)
Added adj actual numbers to LMK settings so user knows the values
Added CRON to wipe different cache every hour ever day and every week
Script now Auto finds your Launcher(s) and has you select from a list (If
yours doesn't show up tell me in this thread and I will add it. I already have over 60 different launchers presearched)
Fixed init.d file (some variables wernt getting sent correctly
Removed some build.prop edits as to fix 3g and wifi issues
I think that's it. But im sure I missed something
V 5.0
Changed delivery of the init.d file
Changed the numbering of the init.d file
Took away 3g/wifi tweaks that were interfering with wifi connecting and toggles not working
Added in checks to remove some conflicting init.d scripts
Added in checks for Selection of aggressivness of OOM (adj & minfree) settings
Added in an option of what I/O scheduler you want to run
Added in a few other build.prop tweaks
Cleaned up some code
V 4.7
Added OOM levels
Added Min free values
Added Min KB values
Added option to choose from AOSP or SENSE
Added Option to Choose from ICS or Gingerbread
Lowered the Wifi option to normal levels for connection issues
V 4.6
Changed ro.ril.enable.a52=1
Changedro.ril.enable.a53=1
Changed net.tcp.buffersize.default=6144,87380,1048576,6144,87380,524288
Changed net.tcp.buffersize.wifi=524288,1048576,2097152,524288,1048576,2097152
Changed net.tcp.buffersize.umts=6144,87380,1048576,6144,87380,524288
Changed net.tcp.buffersize.gprs=6144,87380,1048576,6144,87380,524288
Changed net.tcp.buffersize.edge=6144,87380,524288,6144,16384,262144
Changed net.tcp.buffersize.hspa=6144,87380,524288,6144,16384,262144
Changed net.tcp.buffersize.lte=524288,1048576,2097152,524288,1048576,2097152
Changed net.tcp.buffersize.hsdpa=6144,87380,1048576,6144,87380,1048576
Changed net.tcp.buffersize.evdo_b=6144,87380,1048576,6144,87380,1048576
Added ro.media.enc.hprof.vid.fps=65
Govenor Tweaks for Interactive, Ondemand, OndemandX, SmartassV2, Lulzactive, and Conservative
Changed kernel.msgmni=64000
Cleaned up Code even more
V 4.5
Added a few more tweaks to the 01Smurfed file
Added a few more build.prop tweaks
Hopefully fixed the wifi->3g->wifi issue
Cleaned up the code a little
V 4.1
Changed picture and video settings...camcorder works now
Increased and decreased a few values
Added a huge amount to the init.d file
Removed the minfree values from the init.d (if you want them back I can release one for Gingerbread and one for ICS)
V 4.0
Removed some tweaks that were causing issues
Added in some new tweaks
Changed a few Settings for better response
Script now checks to see if your using a local.prop and if so copies settings to it as well
Now script creates a file in you init.d folder called 01smurfed. This has many new tweaks that will run on every boot
Comments put into script to explain what exactly is going on
Credits given in OP
V 3.3
Removed some setting that were either not necessary or we causing issues for some
Added in some new tweaks I figured out
Fixed 3g not connecting right after turning off WiFi
Fixed WiFi not connecting sometimes
Script now wipes dalvik-cache and requires a restart. Restart will take a little longer due to rebuild of dalvik
I HIGHLY recommend UN-SMURFING before you apply the newest script. I have noticed huge improvements from this last update
V 3.2
Added a few more tweaks
Fixed a typo
Made sure system was remounted as read/write before settings took place
V 3.1
Removed super user check. (Giving errors to some)
Fixed my bad spelling (lol)
V 3.0
Added 10 new edits
Cleaned up code
Made sure temp files were being deleted correctly
Change a number of setting for better tweaking
V 2.0
Huge code change. Now with options.
Now scans and removes duplicate lines
V 1.0
Initial release
Over 30 build.prop edits with more to come.
For a detailed list of settings that this script copies to your Build.prop go to /sdcard/SmurfedBackups/Smurfed_Out.html
!!! WARNING !!!
This Script now interferes with alot of other scripts. I'd recommend unsupercharging and removing some other scripts as well...Tweaks, Read Ahead SD card tweaks, Governor Tweaks, and I'm sure there are a few others. This script searches for some of the scripts mentioned and removers them if found.
Un-SMURF
During the Smurfing process a copy of all removed files is sent the the SmurfedBackups folder on your SD card. When un-smurfing your phone will be restored back to the exact way before Smurfing.
Future Releases
1. Adds in as many battery saving, speed, and responsiveness tweaks as I can find throught out many different forums.
2. removes any other script that is previously installed that may be using same tweaks....if not removing the script itself it will search out each line of each script and remove the lines individually.
FEEDBACK & BUG REPORTS
Please leave feedback after you run so others know how well this script works. I will try my best to help with any bugs that are found. If found please report in this thread with the following info
What Rom are you running?
What Phone are you using?
What settings did you choose in Smurfed Out script?
What Governor are you running?
What kernel are you using?
What things did you try before reporting?
What issues are you running into?
What is your Name and Social Security number? (lol)
What is your Blood Type? (LMAO)
Have you ever thought about donating an organ? (LMFAO)
Syntax Errors or Suggestions
If reporting syntax errors or suggestions to improve the script then please put them into code brackets so I can easily read them and also line number if you happen to remember helps as the script is over 2500 lines now. I appreciate all help with these errors and suggestions to improve the script.
Troubleshooting
My WiFi or 3G doesn't work or wont switch?
Go into recovery and wipe dalvik-cache and cache and reboot.
Check to see if data is enabled in your settings.
Check to make sure if your using a battery saver app like battery xl or juice defender that is not turning off your radios
My camcorder isn't working?
Make sure your using the most recent script. The fix was made available on V 4.1
Does this script work for other phones?
Yes in theory it does. Let me know if it works or not and I'll put it in the OP so others know
I can't get this script to run in script manager?
Make sure you are opening the script with superuser rights within script manager
Can I run this in terminal emulator?
yes type this is command line. also make sure that Smurfed Out is on root of your sd card
Code:
su
sh /sdcard/Smurfed_Out.sh
After running the script and rebooting Im getting a blank black screen?
First scroll down and read just in case and follow those instructions then follow Bug Reporting procedures
My phone got up and ran away from me?
Well this can be a problem....On one hand that would mean that this script really works...on the other hand it means your just not cool enough for you phone anymore and it found someone better.
Just In Case
Build.prop.zip attached is a flashable zip in case of emergency. It has the build.prop of aokp rom in it. If your not running that rom...download the zip. open it up. go into the system folder. Replace the build.prop with the build.prop from the Rom.zip that you are running. Put on your sd card. Flash in recovery. I am putting this here cause in the past there were issues with the script causing a freeze after boot and some people had to nand back or reflash their rom. This will fix that. Enjoy.
[SCRIPT] Smurfed Out V 5.0 (ultimate build.prop/init.d tweaks) Updated 3-18
I/O Scheduler Descriptions
Taken from this post here
Q. "What purposes does an i/o scheduler serve?"
A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?"
A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?"
A.
1) 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.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) 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.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) 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.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6) V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) Anticipatory
Based on two facts
i) Disk seeks are really slow.
ii) Write operations can happen whenever, but there is always some process waiting for read operation.
So anticipatory prioritize read operations over write. It anticipates synchronous read operations.
Advantages:
Read requests from processes are never starved.
As good as noop for read-performance on flash drives.
Disadvantages:
'Guess works' might not be always reliable.
Reduced write-performance on high performance disks.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device
Explanation of Different Governors
Pulled from this page here
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) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
4) 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.
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
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.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
7) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
8) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
9) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
10) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
11) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
12) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. 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.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
13) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
14) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
15) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
16) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
17) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
18) Performance:
Sets min frequency as max frequency. Use this while benchmarking!
So, Governors can be categorized into 3/4 on a high level:
1.a) Ondemand Based:
Works on "ramp-up on high load" principle. CPU busy-time is taken into consideration for scaling decisions. Members: Ondemand, OndemandX, Intellidemand, Lazy, Lagfree.
1.b) Conservative Based:
Members: Conservative, Lionheart, LionheartX
2) Interactive Based:
Works on "make scaling decision when CPU comes out of idle-loop" principle. Members: Interactive, InteractiveX, Lulzactive, Smartass, SmartassV2, Brazilianwax, SavagedZen.
3) Weird Category:
Members: Userspace, Powersave, Performance.
[SCRIPT] Smurfed Out V 5.0 (ultimate build.prop/init.d tweaks) Updated 3-18
Explanation of LMK Settings (Low Memory Killer)
and
Explanation of Adj and Minfree settings
When your phone boots up, a file inside the boot image (init.rc) sets the system parameters. Things like the path to framework files, setting up your networks, and setting the limits at which programs are killed off to free RAM are done by this file. Now a super-Android-geek might dig inside the init.rc file and completely customize the low memory killer, but you don't have to do this to still get good results. The init.rc sets up six different "levels" of open applications. Let's have a look at them:
FOREGROUND_APP: This is the application currently on the screen, and running
VISIBLE_APP: This is an application that is open, and running in the background because it's still doing something
SECONDARY_SERVER: This is a process (a service that an application needs) that is alive and ready in case it's needed to do something
HIDDEN_APP: This again is a process, that sits idle (but still alive) in case it's needed by an app that's alive and running
For the most part, we never want to adjust when these apps and processes are killed off. They are the things that the programs we use need to properly function. For the more bold and advanced users, changing settings for HIDDEN_APP settings is possible, albeit with a LOT of trial and error. There's two more settings, and these are the ones most interesting to us today:
CONTENT_PROVIDER: This is apps that provide data (content) to the system. HTC Facebook Sync? That's a CONTENT_PROVIDER. So are things like the Android Market, or Fring. If they are alive, they can refresh and provide the content they are supposed to at the set interval. If you kill them, they can't of course.
EMPTY_APP: I call these "ghosts." They are apps that you have opened, but are done with them. Android uses a unique style of handling memory management. When an activity is ended, instead of killing it off Android keeps the application in memory so that opening them again is a faster process. Theses "ghost" apps use no battery or CPU time, they just fill RAM that would be otherwise empty. When this memory is needed by a different application or process, the RAM is flushed and made available for the new app. To satisfy the geekier people (like myself) Android does this by keeping a list of recently used apps, with the oldest apps in the list given the lowest priority -- they are killed first if RAM is needed elsewhere. This is a perfect way to handle 'ghost' processes, so there's no need to touch this part
So when you see settings like this 8,14,40,50,60, 75 you start with the first setting and it looks like this
FOREGROUND_APP = 8
VISIBLE_APP = 14
SECONDARY_SERVER = 40
HIDDEN_APP = 50
CONTENT_PROVIDER = 60
EMPTY_APP = 75
You can manipulate these numbers so that they are better managed and give You different aggressiveness and a faster UI
For the Smurfed Out script the settings are as follows
Lite = 8,14,55,70,85,100
Medium = 8,14,75,90,95,125
Max = 25,35,55,70,150,250
Extreme = 25,35,75,90,150,250
Minfrees are set as well but they are equal to the LowMemoryKiller ADJ settings.
I personally run them at Max while using ICS but everyone's experiences will be different.
Nice idea.....good job.
Sent from my PC36100 using XDA App
Looking forward to trying this!
Sent from my PC36100 using xda premium
Interesting
Sent from my PC36100 using XDA App
gonna try this now .
Um, where is the file?
Roman G said:
Um, where is the file?
Click to expand...
Click to collapse
Click on the link that says smurfed out basic
Trying new things never gets old... Let's take her for a spin and see what happens, Thanks Bro!
moreno4xl said:
Trying new things never gets old... Let's take her for a spin and see what happens, Thanks Bro!
Click to expand...
Click to collapse
Feedback is always welcome. As this is the first release I have many other changer that will be taking place in the future on this script nut wanted to release something I had working for now
Papa Smurf151 said:
Click on the link that says smurfed out basic
Click to expand...
Click to collapse
Thanks.
Typing with it now, will report back tomorrow.
I will say I do notice an instant difference, linpack say so as well.
Roman
When I click the link it just opens the file. How do I save it, so I can run it.
nickmus said:
When I click the link it just opens the file. How do I save it, so I can run it.
Click to expand...
Click to collapse
Same with me, I just opened the thread in the browser and saved file by pressing n holding. Renamed it "smurfedoutbasic.sh" and ran it in scripts manager.
Sent from my PC36100 using xda premium
Ya just long press and save. Don't need to rename. Then open it where ever downloads are saved.
Roman
So far I like being Smurfed
Mmmh... Ice Cream Sandwich
Got it using the web browser.
Thanks
Roman G said:
Ya just long press and save. Don't need to rename. Then open it where ever downloads are saved.
Roman
Click to expand...
Click to collapse
What he said lol i had to rename it cause for me it saved as a .bin file
Sent from my PC36100 using xda premium
Sweet. Been seeing the teaser in AOKP thread. Gonna give this a shot and see how it sits in after a day or so.
Sent from my PC36100 using xda premium
I've turned blue and I'm singing
If you spend any time reading Android forums, blogs, how-to posts or online discussion you'll soon hear people talking about the kernel. A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass.
Governors
Kernel Governers
1) Ondemand
2) Ondemandx
3) Conservative
4) Interactive
5) Interactivex
6) Lulzactive
7) Lulzactiveq
8) Smartass
9) SmartassV2
10) Intellidemand
11) Lazy
12) Lagfree
13) Lionheart
14) LionheartX
15) Brazilianwax
16) SavagedZen
17) Userspacce
18) Powersave
19) 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.
Click to expand...
Click to collapse
2) Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
Click to expand...
Click to collapse
3) Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.
Click to expand...
Click to collapse
4) 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.
Click to expand...
Click to collapse
5) Interactivex:
This is an Interactive governor with a wake profile. More battery friendly than interactive.
Click to expand...
Click to collapse
6) Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
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.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
Click to expand...
Click to collapse
7) Lulzactiveq:
Lulzactiveq is a modified lulzactive governor authored by XDA member robertobsc and is adapted in Siyah kernel for GS2 and GS3. Lulzactiveq aims to optimize the second version of luzactive from Tegrak by a) providing an extra parameter (dec_cpu_load) to make scaling down more sensible, and b) incorporating hotplug logic to the governor. Luzactiveq is the first ever interactive based governor with hotplugging logic inbuilt (atleast the first of its kind for the exynos platform). When CPU comes out of idle loop and it's time to make a scaling decision, if load >= inc_cpu_load CPU is scaled up (like original luzactiveq) and if load <dec_cpu_load, CPU is scaled down. This possibly eliminates the strict single cut-off frequency for luzactiveq to make CPU scaling decisions. Also, stand hotplug logic runs as a separate thread with the governor so that external hotplugging logic is not required to control hotplug in and out (turn On and Off) CPU cores in multi core devices like GS2 or GS3. Only a multi core aware governor makes real sense on muti-core devices. Lulzactiveq and pegasusq aims to do that.
Click to expand...
Click to collapse
8) Smartass:
Result of Erasmux rewriting the complete code of interactive governor. Main goal is to optimize battery life without comprising performance. Still, not as battery friendly as smartassV2 since screen-on minimum frequency is greater than frequencies used during screen-off. Smartass would jump up to highest frequency too often as well.
Click to expand...
Click to collapse
9) SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
Click to expand...
Click to collapse
10) Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). 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. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
Click to expand...
Click to collapse
11) Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
Click to expand...
Click to collapse
12) Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
Click to expand...
Click to collapse
13) Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source. Tweaks comes from 1) Knzo 2) Morfic. The original idea comes from Netarchy. See here. 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.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
Click to expand...
Click to collapse
14) LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
Click to expand...
Click to collapse
15) Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
Click to expand...
Click to collapse
16) SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
Click to expand...
Click to collapse
17) Userspace:
Instead of automatically determining frequencies, lets user set frequencies.
Click to expand...
Click to collapse
18) Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).
Click to expand...
Click to collapse
19) Performance:
Sets min frequency as max frequency.
2. I/O SCHEDULERS
Q. "What purposes does an i/o scheduler serve?" A.
Minimize hard disk seek latency.
Prioritize I/O requests from processes.
Allocate disk bandwidth for running processes.
Guarantee that certain requests will be served before a deadline.
So in the simplest of simplest form: Kernel controls the disk access using I/O Scheduler.
Q. "What goals every I/O scheduler tries to balance?" A.
Fairness (let every process have its share of the access to disk)
Performance (try to serve requests close to current disk head position first, because seeking there is fastest)
Real-time (guarantee that a request is serviced in a given time)
Q. "Description, advantages, disadvantages of each I/O Scheduler?" A.
1) 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.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2) Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3) 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.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
4) 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.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
5) SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6)
V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
Q. "Best I/O Scheduler?"
A.There is nothing called "best" i/o scheduler. Depending on your usage environment and tasks/apps been run, use different schedulers. That's the best i can suggest.
However, considering the overall performance, battery, reliability and low latency, it is believed that
SIO > Noop > Deadline > VR > BFQ > CFQ, given all schedulers are tweaked and the storage used is a flash device.
Credits
Internet
This thread http://forum.xda-developers.com/showthread.php?t=1369817
Nice info dude.......
Sent from my GT-I9100 using xda premium
Brilliant work buddy!!
Thanks
Started from the bottom
So, what next..??
BTW, you must made a Thread in General section of android. Containing all links of your work.:highfive:
Disturbed™ said:
So, what next..??
BTW, you must made a Thread in General section of android. Containing all links of your work.:highfive:
Click to expand...
Click to collapse
Guys, you all have made me Tha TechnoCrat from kartiknnn. I am forever indebted to you all. Especially vikesh. My elder brother.
:thumbup:
Started from the bottom
Nice write up
TEAM MiK
MikROMs Since 3/13/11
Good Work Buddy... :good:
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