Android Logo
This is translated from a German post on an XDA-like forum, It’s a good place to start with Governors and the likes. I have changed the dialogue to make a bit more sense in English.
Original Post Here: http://www.usp-forum.de/google-android-forum/86771-faq-kernel-governors-modules-i-o-schedulers.html
Many thanks to Meccs from the Android forum.
A governor is a driver for the regulation of CPUFreq – The CPU frequency in Andorid.
Settings the Max and Min frequencies determines the CPU Core response and medium frequency. The governor determines how long the CPU core should remain at that frequency after it’s been requested. Keeping a CPU core frequency high will impact on battery life.
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.
these are the 22 Governors I have come across so far:
Sleepy (formerly known as Solo) is an attempt to strike a balance between performance and battery power.
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.
It is rather a slow of its kind and is more of a slower Ondemand, which scaled up slowly to preserve the battery. To illustrate an example to hand of the Ondemand. The Ondemand increased interactivity of the smartphone at a frequency up to MaxFreq. The Conservatives on the other hand does slow down by half, saving battery power, but at the expense of performance.
The Ondemand governor is the default choice, due to its balanced settings that offer a good compromise between battery power and
performance. However, he has no profile when you turn off the display (screen off sections) or for waking up the phone and respond to inputs with the same high jumps to perform.
This corresponds to the governor of MaxFreq minFreq. For everyday use, this governor is not recommended.
Here, individual settings instead of automatic defaults are set. Whether it works and how, apparently, no one knows. It’s funny.
This corresponds to the minFreq MaxFreq, exactly the reverse of the Great Power, which means that the performance governor getting the maximum frequency is set, forcing the battery to its knees. Is thus only be used for benchmarks.
This governor is more of a faster Ondemand. Slightly faster and battery-friendly. Instead of regular requests in each interval as the Ondemand,
determined as he scaled the Interactive when the CPU is woken from sleep. He is an intelligent optimization because of its stability Ondemand. This is the most popular governor in recent years.
This is an interactive with profiles and wake-up is also battery friendly than interactive. He basically has the same performance as the Interactive, only with better battery performance.
This is the predecessor of SmartassV2. It limits the MaxFreq when the screen is off. He is not very battery friendly as the SmartassV2. This is because the higher MinFreq when the display is less than the frequency scaling during standby.
This governor is also a reamed Smartass, which is only slightly scaled faster, with the result that these are still somewhat softer and more
responsive, but is also at the expense of battery consumption.
It is similar to the SmartassV2, only more aggressive scaling up, resulting in more power consumption and battery with it.
Another SmartassV2 governor. He achieved a good balance between performance and battery consumption, and is actually underestimated.
This is one of the strangest governors.
It is based on the Conservative, who is known for its slow scale, but in turn, have elements of Smartass, in turn, is known as one of the
fastest skalierfähigen Governor. Some people report that they were fascinated by him. Just hearsay.
This governor of Ezekeel is basically one based on the Ondemand, with the only additional parameter min_time_state, which maintains the minimum time of the CPU on a frequency before scaling up and down. These instabilities are due to rapid change in frequency, such as avoiding the Ondemand. The Lazy governor is indeed more inquiries than the Ondemand, but the frequency changes only after the min_time_state, which goes something like step by step (only 200 MHz, 300 MHz, then 400 MHz, etc.). What’s more, the Lazy-governor of the house, turning off the display parameters (Screenoff_maxfreq) brings, that you can adjust what may be the highest frequency in MHz when switching off the display.
This governor is still fairly new and comes from tegrak. It is based on both the interactive and on the Smartass governor. The slightly older version, if greater than or equal to 60% on their workload, the Governor scaled the CPU to the next level. When the workload was less than 60%, then the governor, the CPU scaled to the next lower level. And when the screen was turned off, then the CPU to the lowest scalable frequency has been locked.
The new version: This version includes three additional configurable parameters. inc_cpu_load, and pump_up_step pump_down_step. These parameters help the user to a greater degree of control. Thus, one can define abzuskalieren the threshold at which the Governor decides to or. You can also specify a certain number of frequency steps that should be skipped when querying.
This governor was a pleasant surprise. Although he leans to the Conservative, he will probably have the best performance of all. He probably did have a slightly worse battery life performance as the SmartassV2, but to the best freshness, which is why he is also the default governor in Nova kernel.
Again, this is similar to the Ondemand governor. The main difference is that it is much battery friendly. The frequency is set to either soft or smooth down raised, unlike the Ondemand, the increase in inquiries rather equal to 100%, although not used. The Lagfree increases so gradually and no skips while the CPU frequency scaling. This also means that the Governor in acute severe power demand does not immediately rise to 100%, and thus to stuttering, such as can occur during video playback.
This is a revised version of the governor of erasmux Smartass. This governor is pursuing the goal of achieving an ideal frequency and attempts to achieve this aggressive and lose less aggressive. He uses different frequencies ideal for switching on and switching off the display. If the display is off, the governor scaled down very quickly (aggressive) and scale of the display when you turn quickly to up to 500 MHz. In contrast to the little brother Smartass, there is no limit on the frequency when the display is off. In this governor is also about a balance between performance and battery life.
The Intellidemand aka Intelligent Ondemand is another faux Governor, based on Ondemand. But believe some users, this is not a substitute for OC governor daemon. The original Intellidemand behaves differently depending on the GPU usage. If the GPU is really busy (games, cards, benchmarking, etc.) that behaves like the Ondemand.
If the GPU is in “neutral” is (that is, claimed more moderate), limiting the maximum frequency of Intellidemand to save depends on the
available frequencies in your device or your kernel to conserve battery power. This is known as browsing mode. We can also find some “traces” of the interactive governor. Frequency-scaling in the lower segment depends on the idle time of the CPU. Low idle-time (<20%) implies a reduction of the frequency-scaling of the current frequency. Frequency scaling reductions occurred in 5% increments from the current frequency.
In summary we can say that this is an intelligent Ondemand governor, who is limited by the browsing mode, the maximum frequency when the GPU
is idle, and if the browsing mode is available, it behaves like the Ondemand if the GPU is not fully utilized. Even the Intellidemand not switch to the highest frequency when the screen is off.
The governor is an optimized Lionheart Conservative governor and it also came from Knzo. It is tuned for extreme performance and responsiveness, unfortunately at the expense of battery power.
This is actually a Ondemand governor, with the only difference is that he brings home from profiles of the switch off and switch on the display. The Governor was created in order to be more battery friendly. If the screen is off, the maximum frequency is set to 500 MHz. In spite of the fact that the Ondemand is present in many kernels as it is considered stable, the support of the Ondemandx far-reaching, because in spite of the fast switching frequency and thus has a low transition delay is just too friendly battery. In this play governor, unlike other Governorn, the I / O schedulers a major role.
He also has the Arighi’s fast_start deep_sleep and detection features. In addition, the maximum frequency is in suspend mode 500Mhz.
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.
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:
Two important things here are indicative of that event:
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
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 th 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
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
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
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
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
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
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.
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.
Leave a Comment