Sirkay,hansip87,jjdoctor for their work in Xperia ray which inspired me to write(Modified and altered from the original thread )
NEW-Check my 3rd post for QUESTIONS AND ANSWERS(21-08-12)-Click here
1. Kernel Governors
These are the 19 governors we're talking about.
Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed
A slower Ondemand which scales up slowly to save battery. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
This is an Interactive governor with a wake profile. More battery friendly than interactive.
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.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
SmartassV2 is a governor (controls the frequency of the CPU at each give moment) which like the first smartass is generally based on the implementation of interactive with some major changes and the addition of a built in sleep profile (behaves a bit differently when screen is off vs. on).The smartassV2 improves the very naive scheme which the first smartass had
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.
Similar to smartassV2. More aggressive ramping, so more performance, less battery.
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
Instead of automatically determining frequencies, lets user set frequencies.
runs minimum speed all the time (good for low battery/high temp situations)
Top speed all the time(better for benchmarking/speed test)
stays at minimum speed until more speed is needed then goes straight to highest speed
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.
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.
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.
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 2-5 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.
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.
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
It set your max cpu for wake and sleep and changes the governor when your device is awake or asleep. It saves battery by lowering cpu frequencys 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 use 2 governors.one for sleep and other for awake)
Governor which is for performance and battery life-smartassV2(To get maximum performance, use ondemand or conservative)
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.
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.
- 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.
- Reduction in number of cpu cycles used is proportional to drop in performance.
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.
- 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.
- When system is overloaded, set of processes that may miss deadline is largely unpredictable.
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.
- Considered to deliver a balanced i/o performance.
- Easiest to tune.
- Excels on multiprocessor systems.
- Best database system performance after deadline.
- 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.
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.
- 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.
- Not the best scheduler for benchmarking.
- Higher budget assigned to a process can affect interactivity and increased latency.
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.
- Simple, so reliable.
- Minimized starvation of requests.
- Slow random-read speeds on flash drives, compared to other schedulers.
- Sequential-read speeds on flash drives also not so good.
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.
- May be best for benchmarking because at the peak of it's 'form' VR performs best.
- 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.