Montag, 18. November 2013


About ART-Dalvik replacement-feature which comes with Android 4.4 KitKat

It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.

What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.

At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from to, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.

How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.

What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!

By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.

Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.

How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…

Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.

Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.

3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.

AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.

For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.

Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.

The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.

To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.


Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.

Introducing ART from:

ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.

Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.

Two runtimes are now available, the existing Dalvik runtime ( and the ART ( A device can be built using either or both. (You can dual boot from Developer options if both are installed.)

The dalvikvm command line tool can run with either of them now. See That is included from build/target/product/ or build/target/product/ or both.

A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/ or build/target/product/

Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart

                                               MANY GREEEETZ+STAY ADDICTED!!!!

Sonntag, 17. November 2013

Know more about your Android CPU

CPU behaviour and its effects on device’s Performance along with its Battery

Everyone is on the hunt for the right balance between the performance and battery of their devices. Everyone wants that their device should run games without any lags and also their device should be able to deliver a good battery backup. But finding this balance takes much more than simply entering power saving mode or reducing the brightness.
As you can guess from the title, this article will focus on the CPU behaviour and how it affects the performance and battery life of your device. So I will start off with this:
What is a CPU?
A CPU(central processing unit)  processes instructions that it gathers from decoding the code in programs and other such files. It has a clock which produces a signal that acts to synchronize the logic units within the CPU as they execute the instructions given in a program. So, the speed at which a CPU processes instructions depends upon the clock speed of the CPU itself.
And now I will relate the above definition to the way the CPU behaviour affects the battery backup and the device’s performance.
Like said earlier, the CPU processes and executes instructions given in a program and the speed with which it processes these instructions would influence the speed with which the program is run. Now to clarify this in relevant terms , the ability of your device to run a program smoothly to its best potential will depend on the speed with which the CPU processes the program’s instructions which implies that it will depend on the clock speed of the CPU. This clock speed is measured in frequencies(Hertz). Thus, the CPU Clock speed refers to the number of times that a CPU’s clock cycles per second. So we would want to have a high operating frequency  for our CPU. But now the battery makes an entry. To run the clock at such high frequencies, the device makes use of the battery power. More the frequency, more the battery is used. So the bottom line is that for good performance you need a higher operating frequency of the CPU but for that equally higher amount of power is used.

Now this brings us to CPU Governors. A governor is a set of commands/instructions which governs the behaviour of the CPU according to different situations. It dictates the CPU to operate at different frequencies depending on the demand. There are many governors which are included in custom kernels. The stock kernel includes the OnDemand, PowerSave, Performance and Conservative Governors. In this article , i will be explaining about these along with the SmartassV2  and UserSpace Governors.
1.  OnDemand - You must have seen this as the first governor as it used as default in stock. As its name suggests, it changes the CPU frequency according to the demand of the system.  It switches to the Maximum CPU frequency as soon as it detects that there is load on the CPU  and then decreases the frequency gradually when the load is less. By all of this, you might think that OnDemand is a pretty reliable governor for the balance between Performance and battery but actually it is not. The frequency change between maximum and minimum is too frequent for the balance. It calculates the requirement to change the frequency to maximum.  This requirement can respond quickly to the workload change, but it does not usually reflect workload real CPU usage requirement. But nevertheless, it is the best stock Governor when it comes to finding the right balance.
2. PowerSave -  A stock kernel made to preserve power. This is pretty straightforward one along with the Performance Governor. It fixes the maximum frequency equal to the minimum frequency of the CPU and always operates in this frequency. This way , the least amount of power is used but the performance is the poorest.
3. PerformanceStraightforward again like PowerSave. It fixes the minimum frequency equal to the maximum frequency such that the CPU always operates at the the highest frequency giving the best performance possible within the stock limits but it uses the power at the highest rate as well.
4. Conservative - It is similar to the OnDemand Governor but is specifically developed to conserve power. It does the operate the same as OnDemand which is changing the frequency based upon the CPU usage but it does this gradually than OnDemand. This means, it does not jump to its next target frequency but instead it moves to its target in steps.
5. SmartassV2 - I not only like its name but this is also my favourite for the balance between performance and battery. It is based on the stock OnDemand but it much more performance and battery friendly than OnDemand. It has the system of ‘Ideal Frequency’. Whenever there is Workload on the CPU, SmartassV2 increases the frequency upto this ideal frequency at a fast rate and then it goes slowly to the maximum frequency. Then when there is less workload, it rapidly scales down.
6. UserSpace - It gives the user the right to set the frequencies at different situations according to the requirement.                                                                                                                                                                        AND MANY MORE PROViDED HERE A FIEW POSTS BELOW

There are many more custom Governors available with custom Kernels but I think these should give you the basic idea of the Affect of CPU behaviour on Performance and battery both. So now go ahead,  download a CPU control app like SetCPU or NoFrills and start finding the apt combinations for your Usage and requirements. You can use Performance Governor in Heavy-demanding games and PowerSave when not using any demanding applications. Or you can use SmartassV2 to handle both of these situations with a decent efficiency. All the best for your hunt!
                                           STAY ADDICTED -CALIBAN666-

(About)Android Memory Management

Android Memory Management 

Most of you must be knowing what Multi-tasking is all about. But this lil overview will take you inside the mechanics of Multi-tasking and give you a closer look.  Lets start off with a basic definition :

Multi-tasking is the ability to run various programs/applications simultaneously in such a way that the user can switch between these programs/applications  at will without  any of the processes being killed.

You all must have heard that different devices have different multi-tasking abilities. And sometimes, even different devices of same models have different multi-tasking abilities. Ever wondered why? Well this is simply because multi-tasking is directly related to the RAM of the device. Its depends on the amount of  RAM ,RAM usage as well as RAM usage management.

Since Android is a Linux system, it has an in-built task killer named as LowMemoryKiller(LMK). The LMK keeps an eye on the RAM usage of all applications in real-time, and when the system has too much RAM consumption, the LMK will start killing apps to free-up some memory. But the way it does that is defined through different sets of  groupings and values but in common terms , you might call these priorities, just the difference that  these priorities are more than simple order.

The LMK distinguishes apps by putting them under categories. Which app will get killed first depends upon the category in which it falls in and the minimum memory threshold of that category. Confused? Let me describe it with the below.

Suppose there are m apps which are being run, The LMK divides all the apps into 6 categories (Out of memory groupings). These have been explained briefly with their decreasing priority

1. Foreground Application - An app that you currently see on the screen. This also includes system and phone.
2.Visible Application - An app that is visible to the user but not at the front possibly because of transparency etc.
3. Secondary Server  - These are applications and services running in the background, it includes launcher, UI etc.
4. Hidden Application - Apps that are not visible but are still running in the background.
5. Content Provider – Processes that provide content for others, examples – Contacts, calender etc.
6. Empty Application - Apps that are essentially in standby and are not doing any work. They can be shut down.
All of these categories have a Minfree Threshold memory value. Whenever the free/Available memory of the system(x) gets less than any of the minfree values, then the LMK starts killing the apps which fall into the category whose minfree threshold value is more than the available memory according to the priorities of the groupings. For example – if  X  is less than memory 2, then the LMK starts killing apps in category 2 to free memory. Obviously, if the available memory is less than the minfree values of more than 1 category, then LMK kills the apps of the category which has the lowest priority first to free up memory.
So, this is how Android manages its memory and now I will explain how it affects the multi-tasking abilities of your Android. As you must have already understood that the in-built memory manager ( LMK) kills app of a specific category only if the available memory is less than the category’s minfree values. If the minfree value is more, then the apps under this category will get killed faster which implies poor multi-tasking whereas if the minfree value is small, the app will not be killed for a longer duration of time until the available memory is less than the small minfree value which leads to better multi-tasking. As default, the minfree values are inversely proportional to the priority of the category i.e. Minfree value of  Foreground Applications < Visible Applications < Secondary Servers < Hidden Applications < Content Providers < Empty Applications.
                                MANY GREEEEETZ AND DONT FORGET TO STAY ADDICTED!!!

Sonntag, 27. Oktober 2013

CALIBAN666 IS ADDICTED TO FLASH: Android Permissions info list to understand what i...

CALIBAN666 IS ADDICTED TO FLASH: Android Permissions info list to understand what i...: Android Permissions info list: When you install an application the Market will tell you all of the permissions it needs to function. These a...

CALIBAN666 IS ADDICTED TO FLASH: Terminal Emulator-Commandlist for Android

CALIBAN666 IS ADDICTED TO FLASH: Terminal Emulator-Commandlist for Android: Android Shell Command Reference --------------------------------- The Android Shell A "shell" is a program that listens to keyb...


CALIBAN666 IS ADDICTED TO FLASH: A GUIDE ABOUT BUILDPROP+INIT.D(KERNEL)TWEAKS!!!!: Build.prop (edit your /system/build.prop with a file manager with root access) Careful for already existing settings. In this case, just ...

CALIBAN666 IS ADDICTED TO FLASH: Build.prop Tweaking,a lil Guide

CALIBAN666 IS ADDICTED TO FLASH: Build.prop Tweaking,a lil Guide: This Guide is for explaining and guiding to tweak the build.prop a lil bit(root needed),only with RootExplorer. ---------------------------...

CALIBAN666 IS ADDICTED TO FLASH: Rom Porting,the easy and lazy Way!!!!!

CALIBAN666 IS ADDICTED TO FLASH: Rom Porting,the easy and lazy Way!!!!!: Have tested many times and it have ever worked,but its recomned to read and follow the Guide. ---------------------------------------------...


CALIBAN666 IS ADDICTED TO FLASH: (TUTORIAL)FLASH/USE LG-p700 CUSTOM ROMS on LG-e610...: Here is step by step guide with the steps that im do for have working L7 Roms on my L5-e610 NFC Model,should work for e612 too. -----------...

CALIBAN666 IS ADDICTED TO FLASH: Understanding CPU Governors and Scheduler

CALIBAN666 IS ADDICTED TO FLASH: Understanding CPU Governors and Scheduler: 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 de...

Understanding CPU Governors and Scheduler

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

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 bitch 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: Lulzactive
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®, 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.

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? 

  1. CFQ
  2. Deadline
  3. VR
  4. Simple
  5. Noop
  6. Anticipatory
  7. BFQ
  8. Sio

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.

- 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

- 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.

- 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

- If the system is overloaded, can go a lost set of processes, and is not as easy to predict

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.

- Is the best scheduler for benchmarks

- 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

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.

- 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

- Reducing the number of CPU cycles corresponds to a simultaneous decline in performance einhergehendem

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.

- 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

- 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.

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.

- Requests of read accesses are never treated secondarily, that has equally good reading performance on flash drives like the noop

- Requests from process operations are not always available
- Reduced write performance on high-performance hard drives

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.

- It is simple and stable. - Minimized Starvations (starvation) for inquiries

- Slow random write speeds on flash drives as opposed to other schedulers. - Sequential read speeds on flash drives, not as good

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.