Thanks to deedii for posting this in another forum:
http://forum.xda-developers.com/showpost.php?p=26884865&postcount=2
Android CPU governors explained
What is a governor?
A governor is a driver for the regulation of CPUFreq - CPU frequency. As the name suggests, we, the Governor of the decision, when at full capacity, the MaxFreq - will be achieved or how fast the minFreq - - maximum frequency is reached minimum frequency or center frequency. He decides when, how and how long the CPU and still responds battery saving is still soft and still works.
There are many types of governors. Some are for single-core processors and some designed for dual-core processors. In stock kernel, there are five governors and quasar kernel, there are a lot more.
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: Wheatley
23: Lulzactive
24: AbyssPlug
25. BadAss
26. Ktoonservative
27. AssWax
28. Sleepy
29. Hyper
30. Zen
31. Dyninteractive
32. SmartassH3
33. Smartmax
34. Pegasusq
35. Nightmare
36. Darkness
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
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: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
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
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
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
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think 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 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: 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.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 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 will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. 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.
21: Hotplug Governor:
The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.
The key difference in the “hotplug” governor is that it will disable auxillary CPUs when the system is very idle, and enable them again once the system becomes busy. This is achieved by averaging load over multiple sampling periods; if CPUs were online or offlined based on a single sampling period then thrashing will occur.
Sysfs entries exist for “hotplug_in_sampling_periods” and for “hotplug_out_sampling_periods” which determine how many consecutive periods get averaged to determine if auxillery CPUs should be onlined or offlined. Defaults are 5 periods and 20 periods respectively. Otherwise the standard sysfs entries you might find for “ondemand” and “conservative” governors are there.
Obviously, this governor is only available on multi-core devices.
22: Wheatley
in short words this govenor is build on “ondemand” but increases the C4 state time of the CPU and doing so trying to save juice.
23: Basically interactive governor with added smartass bits and variable (as opposed to fixed amout) frequency scaling, based on currently occuring cpu loads. Has, like smartass, a sleep profile built-in. See link for details on exact scaling.
24: Abyssplug governor is a modified hotplug governor.
25. BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
26, Ktonnservative
Ondemand scales to the highest frequency as soon as a load occurs. Conservative scales upward based on the frequency step variable which means for the most part will scale through every frequency to achieve the target load thresholds. What this practically means is ondemand is prone to wasting power on unneeded clock cycles. Ondemand also features something called a down differential, this variable determines how long the governor will remain at the given frequency before scaling down. Conservative does not have this, but instead relies on having a down threshold which insures that as soon as the load drops below a given variable it scales down as fast as the sampling rate allows. The result to this is a governor which attempts to keep the load level tolerable and save you battery! Now ! Ktoonservative Is that but in addition contains a hotpluging variable which determines when the second core comes online. The governor shuts the core off when it returns to the second lowest frequency thus giving us a handle on the second performance factor in our CPUs behavior. While by default conservative is a poor performer it can be made to perform comparably to even performance governor. Here are some settings to discuss and start with. They are slightly less battery friendly under a load but very very well performing.
27. AssWax
So far, all I have found about this Governor is that it belongs in the interactive family. I'll update this when I find more
28. Sleepy
The Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power to create. It is based on the getweakten Ondemand of Arighi and is optimized for the SGS2. It may include imoseyon's Ondemandx with some tweaks Down_sampling and other features that set by the user through the sysfs of "echo" call. Sleepy is the behavior of Ondemandx when he is in action, very similar.
29. Hyper
The Hyper (formerly known as kenobi) is an aggressive smart and smooth, optimized for SGS2 getweakt and, based on the Ondemand, which was getweakt of Arighi and was equipped with several features of Ondemandx suspend imoseyon. (Added by sysfs, the settings suspend_freq and suspend Imoseyon's code) is the behavior of the hyper Ondemand if he is in action, very similar. He also has the Arighi's fast_start deep_sleep and detection features. In addition, the maximum frequency is in suspend mode 500Mhz.
30. Zen
Well, the question that was asked above led me to an analysis of V(R ), deadline, and some others. I already knew, but realized "this is the main feature of V(R), but wait it has no benefit to us smartphone users." So I thought about adjusting the way V(R ) handled requests and how it dispatched them (I chose V(R ) because i'd rather not tinker with a scheduler thats official and widely supported). Then I was looking over it, and realized I might as well just write a new one I don't need any of this stuff. So I came up with something awfully similar to SIO, although its a bit simpler than SIO (closer to no-op) and works just slightly different.
- It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op. (Credit bbedward http://forum.xda-developers.com/showthread.php?p=33327389)
31. Dyninteractive
All I can find about this governor is that the DynInteractive seems to behave perfectly in terms of frequency ramping so far and keeps the system running mostly on low clock speeds, unless really needed (games, heavy browsing, etc).
32. SmartassH3
The SmartassH3 governor is designed for battery saving and not pushing the phones performance, since doing that drains battery and that's the one thing people keep asking for more of.
33. Smartmax
This is a new governor which is a mix between ondemand and smartass2 By default this is configured for battery save - so this is NOT a gamer governor! This is still WIP!
34. Pegasusq
Read This: Pegasusq Governor
35. Nightmare
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery.
In addition to the SoD is a prevention because it usually does not hotplug.
36. Darkness
It's based on nightmare but more simple and fast, basic configs but very complex structure. * Alucard updated nightmare gov and improved stability, so far what stable in tests
Credits goes to:
http://icrontic.com/discussion/95140/android-cpu-governors-and-you-setcpu-system-tuner-tegrak
http://forum.xda-developers.com/showthread.php?t=1369817
What is a scheduler?
In a multitasking operating system, there must be an instance, the processes that want to run, CPU time and allocates it "goes to sleep" after the allotted time (timeslice) again. This instance is called the scheduler, such as opening and closing applications. that is, how fast they are open and how long they are kept in RAM.
I / O scheduler can have many purposes like:
To minimize time searching on the hard disk
Set priorities for specific process requests
To regulate a particular portion of the bandwidth of the data carrier to each running process
To guarantee certain process requests within a certain time
Which scheduler are available?
CFQ
Deadline
VR
Simple
Noop
Anticipatory
BFQ
Sio
Row
Anticipatory:
Two important things here are indicative of that event:
- Looking on the flash drive is very slow from Equip
- Write operations while at any time are processed, however, be read operations preferred, ie, this scheduler returns the read operations a higher priority than the write operations.
Benefits:
- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like the noop
Disadvantages:
- Requests from process operations are not always available
- Reduced write performance on high-performance hard drives
CFQ:
The CFQ - Completely Fair Queuing - similar to the Dead Line maintains a scalable continuous Prozess-I/O-Warteschlange, ie the available I / O bandwidth tried fairly and evenly to all I / O requests to distribute. He created a statistics between blocks and processes. With these statistics it can "guess" when the next block is requested by what process, ie each process queue contains requests of synchronous processes, which in turn is dependent upon the priority of the original process. There is a V2 and the CFQ has some fixes, such as were the I / O request, hunger, and some small search backward integrated to improve the responsiveness.
Benefits:
- Has the goal of a balanced I / O performance to deliver
- The easiest way to set
- Excellent on multiprocessor systems
- Best performance of the database after the deadline
Disadvantages:
- Some reported user that the media scanning would take this very very long time and this by the very fair and even distribution of bandwidth on the I / O operations during the boot process is conditioned with the media scanning is not necessarily the highest should have priority
- Jitter (worst case delay) can sometimes be very high because the number of competing with each other process tasks
Deadline:
This scheduler has the goal of reducing I / O wait time of a process of inquiry. This is done using the block numbers of the data on the drive. This also blocks an outlying block numbers are processed, each request receives a maximum delivery time. This is in addition to the Governor BFQ very popular and in many well known kernels, such as the Nexus S Netarchy. He was indeed better than the BFQ, but compared to the VR he will be weaker.
Benefits:
- Is nearly a real-time scheduler.
- Characterized by reducing the waiting time of each process from - best scheduler for database access and queries.
- Bandwidth requirements of a process, eg what percentage does a CPU is easy to calculate.
- As the Governor-noop ideal for flash drives
Disadvantages:
- If the system is overloaded, can go a lost set of processes, and is not as easy to predict
SIO:
It aims to achieve with minimal effort at a low latency I / O requests. Not a priority to put in queue, instead simply merge the requests. This scheduler is a mix between the noop and deadline. With him there is no conversion or sorting of requests.
Benefits:
- It is simple and stable. - Minimized Starvations (starvation) for inquiries
Disadvantages:
- Slow random write speeds on flash drives as opposed to other schedulers. - Sequential read speeds on flash drives, not as good
Noop:
The noop scheduler is the simplest of them. He is best suited for storage devices that are not subject to mechanical movements, such as our flash drives in our SGSII's to use to access the data. The advantage is that flash drives do not require rearrangement of the I / O requests, unlike normal hard drives. ie the data that come first are written first. He's basically not a real scheduler, as it leaves the scheduling of the hardware.
Benefits:
- Adds all incoming I / O requests in a first-come-who-first-served queue and implements requests with the fewest number of CPU cycles, so also battery friendly
- Is suitable for flash drives because there is no search errors
- Good data throughput on db systems
Disadvantages:
- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance einhergehendem
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. The VR is a very good scheduler with elements of the deadline scheduler. He will probably be the best for MTD Android devices. He is the one who can make the most of the benchmark points, but he is also an unstable schedulers, because his performance falter. Sometimes they fluctuate below the average, sometimes it fluctuates above the average, but if above, then he is the best.
Benefits:
- Is the best scheduler for benchmarks
Disadvantages:
- Performance variability can lead to different results
- Very often unstable or unzverlässig
Simple:
As the name suggests, it is more of a simple or simple scheduler. Especially suitable for EMMC devices. He is reliable, maybe not as good as the VR, when this time has a good day, but he is despite all this very performance-based and does his best. At the moment it is the default scheduler in quasar kernel.
Advantages: - not known
Cons: - not known
BFQ:
Instead requests divided into time segments as the CFQ has, on the BFQ budget. The flash drive will be granted an active process until it has exhausted its budget (number of sectors on the flash drive). The awards BFQ high budget does not read tasks.
Benefits:
- Has a very good USB data transfer rate.
- Be the best scheduler for playback of HD video recording and video streaming (due to less jitter than CFQ Scheduler, and others)
- Regarded as a very precise working Scheduler
- Delivers 30% more throughput than CFQ
Disadvantages:
- Not the best scheduler for benchmarks - higher budgets that were allocated to a process that can affect the interactivity and bring with it increased latency.
Row:
Q: What is the ROW I/O scheduler?
A: ROW stands for "READ Over WRITE"
The ROW IO scheduler was developed with the mobile devices needs in
mind. In mobile devices we favor user experience upon everything else,
thus we want to give READ IO requests as much priority as possible.
In mobile devices we won’t have AS much parallel threads as on desktops.
Usually it’s a single thread or at most 2 simultaneous working threads
for read & write. Favoring READ requests over WRITEs decreases the READ
latency greatly.
How can I change the governor and scheduler?
There are two ways to change the governor and schedulers, as well as the settings for the Governorn. Either manually, in which you use a file manager like Root Explorer and then knows how to / sys / devices / system and then change the files to his wishes, provided you what you're doing, or via a graphical interface or by phone as SetCPU Voltage Control. These are the most prominent apps when it comes to adjusting the governor and / or scheduler.
- SetCPU are, besides the possibility of the clock speed of the CPU, setting profiles in certain situations, only to change the way the governor. The scheduler can not change it.
- Voltage control can alter both the governor and the scheduler, but has no way to adjust behavior profiles. While you can set various overclocking, Governor and scheduler profiles manually, but nothing more. Nevertheless, I prefer the VC, since it is simple and gives me the opportunity to change the scheduler.
Credit goes to [url="http://tinzdroid.blogspot.com/2012/07/android-kernel-governors-modules-io.html]Tinzdroid[/url]
Damn learn something new today. Bookmark this page....
that dude drives a A-Team van. yeah that's right, I'm working on it. Z.R.T.
hey hip kat which are you running?
SmartassV2.
Seemed like the best mix of performance vs. battery life from what I was reading.
link to Wheatley:
http://forum.xda-developers.com/showpost.php?p=21864389&postcount=75
link to lulzactive:
http://tegrak2x.blogspot.com/2011/11/lulzactive-governor-v2.html
good reading hipkat..... thanks for the info
Nice info, thx mate
This was really helpful, thanks!
Dude thank you for this writeup. Extremely helpful. OndemandX works great on Sense ROMs IMO
Thanks for the info .
I'm gonna sticky this as the info is great to have for users. The only thing I ask is that along with credits you attach a link to the original thread please.
xda moderator/recognized contributer
Thank you, Papa!!!
I'll go look for it and get the link in here asap
I'll update it, too, as I learn about the newer governors that come out, etc.
thanks for the info
Thanks, now how about schedulers noop or bfq
jasonwojo75 said:
Thanks, now how about schedulers noop or bfq
Click to expand...
Click to collapse
Good idea, plus there are newer governors coming out that I need to get added to the OP
Wow man, summed it up pretty damn good. I was curious as to what differences there were between all the governors out there.
Well written and in-depth, this helped my understanding of them a great deal, you are thanked.
Performance Governor
I thought too that running at "Performance" governor was a crazy idea, and I just tried setting it on my HD2 at around 1:10 PM today, little over an hour ago. I'm on NexusHD2-ICS-4.0.4-CM9-HWA V2.3 ( tytung_HWA_r3), BDW. I'm running gmail, Skype and other "push" apps on the background all the time, and WiFI is constant ON.
To my surprise, after looking at SystemPanel history, the battery has been flat for almost an hour! (See screenshot attachment)
So I guess the theory is correct, where the variable bitrate (up/down scaling) consumes more cpu and battery that just runing full speed while processes demand it, and then fast fall time to low power. So fast rise/fast fall seems to be best battery saver and performance.
More tests need to be done, but so far, I hadn't seen my battery consumption this good, with any other governor!
Cheers
I totally agree with that, that scaling up and down puts more of a load on the cpu. Think about a car motor. Idling, vs revving it over and over
Awesome thread! This helps a lot on which gov to use! +1
Nice thread. I personally like SavagedZen. 2nd choice is Wheatley.
This is a simple STARTER GUIDE to kernel features/parameters and everything you need to know about custom kernel goodies before you consider flashing them. Now that there are a few custom kernels out there for our device, you may want to know about these.
I’d be glad if you could help me complete this guide.
First of all I’d like to thank all kernel guys who put countless hours into this to bring us the features which I am going to explain soon.
Overview:
Post 1:
A.: What you want to know about the CPU/GPU of your device
B.: Custom Kernel Features
Post 2:
Coming Soon!!!
A: What you may want to know about the CPU/GPU of your device:
Galaxy Note 10.1 features a 1.4GHz Quad Core CPU (Exynos 4412) and a 400MHz GPU (Mali-400).
More Data will be added soon.
B.1: CPU/GPU/IO Features which comes with Custom Kernels:
OC/UC (As for OverClock/UnderClock):
As you may know, CPU or any other processing unit features a clock frequency. Over/Under Clock simply means raising/decreasing the clock frequency of CPU.
Reason: Why would one need to overclock? Because one needs more processing power. For example if you want to experience smoother gameplay when playing high-graphic games.
Why would we need underclock? Higher processing power demands more battery. So underclocking helps us, reserve more battery. As for HOX, searching internet and texting don’t need much of processing power. So we can limit the processing power and save battery during low use of our device.
•Note1: OC/UC is not limited to CPU. GPU is also capable of OC/UC. And the interface for that is NOT available in the current custom kernels of Note 10.1.
•Note2: Gamers may not use GPU UC. Limiting GPU processing power impact significantly on your gaming experience.
UV (As for Undervolt):
Every frequency of a processing unit, demands a certain amount of power to be supplied. Undervolting to put it simple means decreasing the voltage of a certain frequency (or all of them).
Reason: The more voltage CPU/GPU gets, more heat will be generated. So mainly we UV to decrease the generated heat of CPU/GPU.
•Note1: One Frequency needs a certain minimum amount of voltage to perform correctly and the system be stable. Undervolting more than a certain amount of voltage will cause system instability.
•Note2: UV improves battery life by using less power. See this.
CPU Governors:
Frequency scaling is the means by which the Linux kernel dynamically adjusts the CPU frequency based on usage of the device. Governors refer to schemes which dictate to the kernel how it should do these adjustments. (From rootzwiki)
To put it simple, Governors are the way that CPU frequency is adjusted according to the demand of operating system.
Selecting a proper governor for your CPU is crucial to the performance and battery preserving of your device. For example if you are low using your device you may use a more battery friendly governor and if you want to play games you may use a more power consuming performance governor.
•Note: See Droidphile’s Great Guide about Governors to be familiar with each one of them and the ones that you should use in different situations here.
I/O Schedulers (As for Input/Output):
Input/output (I/O) scheduling is the method that computer operating systems use to decide which order block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'. (From Wikipedia)
To put it simple, Schedulers are the way reading and writing to the SD card is managed.
The same things that is said in the Governors part is applied here, too.
•Note: See Droidphile’s Great Guide about Schedulers here.
ReadAhead buffer size:
In terms of reading data from SD card, there is a cache which is used as a buffer. The size of that cache is readAhead buffer size. The size has a direct impact on your reading speed of your SD. So giving it a right amount is crucial.
File System “X” R/W (As for Read/Write):
Android by default doesn’t support all the File Systems (What are file systems?! See here). So some kernels may add certain file system R/W. The most popular unsupported file system is NTFS.
B.2 Features of Custom Kernels (AKA Goodies!!!):
MultiCore PowerSaving:
This feature try to group up tasks in the least cores possible. To put it simple, it will focus in using least cores for your tasks to be done. This means less cores are active and so more battery life. Also this will decrease performance.
•Note: To enable use TricksterMod app. 0 for disable and 2 for the most aggressive.
CIFS:
In order to manage your cifs/nfs network shares on your Android device you need the proper and working modules. And so you can mount/unmount your network accessible file resources and access your data.
B.3 Other Features:
Init.d Support:
There are some scripts that run every time your device boot up which are located in /etc/init.d Those are called init.d scripts. One of the most popular init.d scirpts that is available for Note 10.1 is this.
Eco Mode - NEW:
Eco Mode is an optimized dual core solution for quad-core SOC (System on Chip) like the Qualcomm S4-pro. This should allow for Maximum battery life without sacrificing performance. - Paul Reioux
TCP Congestion Control:
The choices in this section, address how the operating system kernel manages flows of information in and out of the kernel, which is at some level the "switchboard operator" of your handset. More info here.
Better to leave this options as is. Cubic or Westwood as the default of your kernel.
Dynamic FSync - NEW:
fsync is a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data. (From here).
Dynamic FSync, makes it possible for fsync operation to be asynchronous when the screen is on, and synchronous when the screen is off. And what does asynchronous mean? Means OS issues fsync call, but not necessarily immediately at commit time for each transaction. It delays the FSync call for a certain amount of time. In case of a crash, the transactions not yet sync'ed in the last delay time before the crash may be rolled back, but the state of the data is always consistent. (From here).
zRAM:
In order to explain zRAM more precisely first we need other terms defined clearly:
Swap can be compared with the swap file on Windows. If the memory (RAM) is almost complete, the data which is not used actively (ex. background applications) will be stored on hard drive so as to re-evacuate RAM free. If required, this data is then read back from there easily. This will preserve performance with no lose at multitasking (the main reason we use swap).
In zRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (zRAM). So in other words, zRAM is a kind of swap in memory. As the data is compressed not much memory needs to be preserved as zRAM. However, the CPU has to work more because compressed data has to be unpacked again when it is needed). The advantage clearly lies in the speed. Since the swap partition in RAM is much faster than this is a swap partition on a hard drive.
In itself a great thing. But Android does not have a swap partition, and therefore brings Android ZRAM under no performance gain as would be the case with a normal PC. (From here with some editing.)
Click to expand...
Click to collapse
What we need to know essentially lies here:
zRAM off = Low use data will be stored the way they are in the memory. This will cause no extra load on CPU, yet need more RAM.
zRAM on = Low use data will be stored compressed in the memory. This will cause extra load in CPU as to store or restore data, yet preserve more Free RAM.
The main use of zRAM is when you are using a heavy ROM that eats up all your RAM. This will allow multitasking to be more functional. On light ROMs, or for those who don't multitask much, this is not necessary.
Note: Also there are methods to use a part of internal memory as Swap space. This is not as fast as zRAM. But no RAM will be used at all and CPU load is less. Though I am not sure that this has been brought to our device yet. Will add more data soon on this part.
Work in progress, will add more info soon.
Reserved for OP
csec said:
•Note2: UV does not impact battery life (or it is not noticeable).
Click to expand...
Click to collapse
First of all, I would like to praise this guide for its information and depth, secondly I would like to help improve it;
emprize said:
the only different for me is temperature, for battery saving, always not noticeable for me, placebo effect most likely
Click to expand...
Click to collapse
AndreiLux said:
This is a nonsensical argument, temperature aka heat, is power. If you are getting a less heated phone, then your battery life is improving. If this wouldn't be the case then you are holding the solution to the world's energy problems in your hands.
Click to expand...
Click to collapse
just thought i would share some thoughts of a well respected and knowledgeable developer.
http://forum.xda-developers.com/showthread.php?p=36723175#post36723175
Regards
Jack
JSale said:
First of all, I would like to praise this guide for its information and depth, secondly I would like to help improve it;
just thought i would share some thoughts of a well respected and knowledgeable developer.
http://forum.xda-developers.com/showthread.php?p=36723175#post36723175
Regards
Jack
Click to expand...
Click to collapse
Wow, that was hell of an argument. Seems to be theoretically true. What I referred to in above is real life experience with my phone and according to kernel guys down at HOX forums.
However the information was really interesting. I will add it to the OP.
Thanks.
Sent from my GT-N8000 using Tapatalk HD
Recently Added to the OP:
- Eco Mode
- Dynamic FSync
zRAM added to the guide.
I/O SCHEDULERS
Thnx to @droidphile for clearing the concepts.
Here each & every concept of I/O Sched. is very clearly explained.
After reading the post i can assure u that will have sufficient knowledge about I/O Schedulers & u will be able to choose I/O schedulers easily which suits ur needs & and the phone best depending upon the type of work load u put on ur Android Smartphone.
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)
Description, advantages, disadvantages of each I/O Scheduler?
List of I/O Schedulers:-
1) Noop
2) Deadline
3) CFQ
4) BFQ
5) SIO
6) V(R)
7) Anticipatory
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 queues 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.
Frequently asked questions
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.
Q. "How do i change I/O schedulers?"
A.Voltage Control or No Frills from market.
Or init.d script:
echo "scheduler-name" > /sys/block/mmcblk0/queue/
scheduler
------------------------------------++END++---------------------------------------
Press Thanks :thumbup: If I Helped U
Very useful information [emoji106]
u forgot the default scheduler of g2... Row..
Varun hellboy said:
u forgot the default scheduler of g2... Row..
Click to expand...
Click to collapse
Oops I m going to add it and Let u Know .
The inner intricacies and mechanics of digital systems never cease to amaze and excite me, as an engineer. This is what it's all about - beyond the gloss and the polished glass, under the hood, deep down at the transistor & gate level. What an amazing time we are living in
Thank you for posting this, God bless you. Happy Christmas.
These tips are based in my study and experience of using different programs and techniques to get solid and stable performance from custom kernels. It's a long read, but a good read if you really want to minimize heat and maximize performance. This information works on any custom kernel that can be used with Synapse. This guide is aimed at beginner and intermediate users who are interested in custom kernel settings but don't know where to start. These are the most commonly optimized settings on Android.
***DVFS Rule #2 is exclusive to Samsung devices (so if you don't have a Samsung device don't use it!)***
Rule 1: What works for some won't work for others - This has always been the most important rule of custom kernels. One person using Barry Allen governor, overclocked to 3.07 GHz, and not using intelliplug will never hit 70C while your phone using those same settings might immediately cause the phone to reboot. All synapse changes made to a device must be tested by you to ensure compatibility for your hardware. Some of you may be curious, if this is the case, why Google would have everyone use the interactive governor by default? I would respond to you that they originally assigned everyone to OnDemand while they worked to make a better and more compatible Interactive governor. But as you know there are a LOT of governors out there and knowing what is best for your device is to read and to test it. The good news is that once you find something that works well you can stick with it as long as you own the device.
Rule 2: DVFS (Dynamic Voltage and Frequency Scaling) Disabler - This is mentioned in a few threads, but requires a repeat. Samsung uses DVFS to contol your CPU frequencies and voltage levels. This isn't an issue when you're running a stock kernel because it works in conjunction with MP-Decision to decide on the proper frequency level. When you're running emotion kernel you don't want DVFS to control anything. You want it to let Faux's Intellithermal work together with the kernel routines to shut down cores it doesn't need.
R2 Part 1: If your phone is running hot: Install Xposed, download Wanam Xposed (enable the module), Open Wanam, click "Advanced" menu, Uncheck "Enable TouchWiz DVFS" and reboot.
R2 Part 2: Following the reboot open Synapse, scroll over to CPU Drivers scroll down and put a checkbox in "Enable Intelli-hotplug", leave the rest alone, and click the check mark at the top of the screen to save changes. Scroll over one more screen to "Thermal" and put a check in the box, "Enable or Disable Intelli Thermal Control" and leave the settings below as they are unless you know what you are doing.
Note: The phone will be still be warm for awhile, but if you give the phone a break and allow the heat to dissipate it should run cooler and more consistently with the added bonus of shutting down 3 out of the 4 cores unlike MP-Decision which always leaves 2 cores live. After doing this if you are noticing performance loss or stuttering it's time to find a new governor that makes the most of these settings. Which leads me to Rule 3....
Rule 3: Choosing a new governor - This part is going to require some reading on your part, but I can assure you that it is worth your time. This guide http://forum.xda-developers.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957 by @gsstudios is OUTSTANDING (please thank him while you are there) and carries a LOT of information about the governors and other performance informations. So find something you like from the guide descriptions to try out and leave it in place for 24 hours or more as long as you aren't experiencing excessive lag or reboots. If it performs well under normal usage the next step is to watch battery life. There won't be a single governor that does everything perfectly, but finding something that fits your needs is key. And it's OKAY if you decide to stick with Interactive, it is a very well made governor and many are based off of that design, but I equate it to finding a good pair of shoes. Lots of things will protect your feet from the ground, but shoes that you enjoy and work well make all the difference in the world.
NOTE: You can use Antutu for stability testing but do not pick a new governor and then run benchmarks and expect top score unless you chose the performance governor. Antutu specifically maxes out your device voltage and frequency to see what the device can handle which is not what intelliplug is for. If you are following this guide benchmarks are the least of your concerns.
Rule 4: Don't forget your Scheduler - Believe it or not, everything runs off of your phone storage. So using an optimized scheduler for you device could make great strides in battery and performance improvements. Unlike choosing a governor, you can absolutely benchmark your flash memory to find out which scheduler works best for you. I only use one and I am going to shamelessly plug it here: I use Android Tuner to benchmark my flash speed with different schedulers and it works great for me. How it works:
Note:To help with choosing where to start with schedulers you can use the guide I linked to above which will give you an idea of what to use. That guide has an exceptional amount of information about how these types of schedulers work and what you should use for getting what you want from your phone. What follows is my advice for testing benchmark write performance and those steps are completely optional, but it never hurts to see how your device does with your chosen scheduler.
R4 Part 1: Launch Android Tuner, from the main menu accept root, acknowledge that root is powerful, scroll all the way to the far left screen, choose "SD Card Read Speed", click "Benchmark in the center, and then notice at the top you have /storage/emulated/0 which is your faster internal memory (which you should optimize first) and then /storage/ExtSdCard which you can benchmark second.
R4 Part 2: When you are ready to benchmark choose your "I/O Scheduler" from the drop down menu and click "Run". Your results will be listed with the fastest read-ahead size on the left and the speed at which it read on the right. Higher = Better -- Then you would choose the other test size (10MB in my case) and you see which readahead value is the fastest for those files. If you manage to get a readahead that the 100MB and 10MB test highest values are the same, then you've won the lottery. Since that is almost impossible try to remember what your top 5 fastest are and choose the one that performs well in both tests. If you want to keep testing and check other schedulers for raw read speed just switch them at the top and re-run both tests.
After you've found which scheduler gives you the performance you want, go back to Synapse, scroll to "I/O" tab, and adjust pick your scheduler and readahead value, and finally click the check mark to apply it.
Rule 5: Undervolting (IMO) does more harm than good - I'll let you Google it but it follows the rule of diminishing returns. You might be running Synapse and are able to undervolt 75mV and still cruise through menus and apps like it's no problem. But I promise you at some point the CPU is going to call for that voltage you starved it of and it will reboot. It's not a matter of if it will happen, but when it will happen. This comes down to your personal silicon and I do not recommend undervolting at all. Other more advanced users may disagree with me, but for the average user there are better ways to save battery and negate heat than starving your CPU and GPU at a kernel level. Especially with DVFS disabled.
And that's all I have for you. These tips work for any custom kernel that uses Synapse to manage their settings. I've personally test my setup with Emotion and the kernel we are not to speak of on XDA. If you like the idea of getting the most out of your device then a custom kernel might be for you, but it requires a lot of patience. If you just need something that works I definitely recommend the stock kernel because they really did a good job with the Lollipop release of our kernel.
I hope this helps some of you and I hope that everyone can take something away from this guide. Feel free to let me know if this helped you in some way or if you need some guidance on the topic. I'll do my best to backup my claims with proper research and documentation.
Thanks
Google - For research help and a great phone OS
Linux - The foundation of this OS
gsstudios - For his outstanding guide and work on researching this information (Definitely hit 'Thanks' on his post)
Note 4 ROM and Kernel Devs - we are very lucky to have a lot of great devs for our device; their work is appreciated and gives me something to write about
XDA and their members - where I've learned most everything about one of my favorite operating systems