Starting with a series of "What is.." inside the android Linux kernel, here is the first article about the Linux cpu governor. If you flashed a custom rom you probably heard about the cpu governor and you maybe asked yourself, why is this thing such a buzzword, where nearly every developer for a custom kernel/rom states out her/his governor is the best? First the obvious; its part of the cpu system inside the kernel and exactly this makes it a huge player on your device performance and battery life.

Now why is it so important?

As you probably already know, your phone has built in a CPU (= central processing unit). This unit is responsible for many core operations such as calculations. CPUs do come in very different shapes and sizes and are important for modern computing. Many of those modern CPUs have multiple cores. Its very likely that your mobile phone has more than one core, for a better understanding i will focus only on single-core CPUs on this article. A CPU has typically a clock frequency which it can run on. Those frequencies vary from CPU to CPU and even worse a desktop CPU with 1.0 GHz is not comparable to a mobile device 1.0 GHz CPU.

In line with the growth of the Linux kernel there was a need for some sort of policy management for those frequencies, because nearly all CPUs are not locked on a single frequency. In fact many CPUs have several frequencies where they can scale in between. It was obvious that this should be done via an effective implementation like other parts in the kernel too. The results were some pretty simple approaches along with a new subsystem for the Linux kernel called the cpufreq driver.

 

Performance Governor

As you might assume, this governor stands for performance. Basically it locks the maximum frequency for the CPU at its highest, which means there will be no scaling and the CPU is forced to run at its maximum speed at any time. In return, this means the kernel won't need to care about increasing or decreasing the frequency and can just do other stuff. This is the governor with the highest performance gain, no other governor will compete with it, no matter how good they are.

A quick look at its source code reveals its simplicity;

static int cpufreq_governor_performance(struct cpufreq_policy *policy,
					unsigned int event)
{
	switch (event) {
	case CPUFREQ_GOV_START:
	case CPUFREQ_GOV_LIMITS:
		pr_debug("setting to %u kHz because of event %u\n",
						policy->max, event);
		__cpufreq_driver_target(policy, policy->max,
						CPUFREQ_RELATION_H);
		break;
	default:
		break;
	}
	return 0;
}

 

Powersave Governor

Performance might not always what you've been looking for. Some systems need to run 24/7. Its pretty bad to waste power if you don't need it, because the higher the frequency of a CPU the more energy it will consume. Thats when the Powersave governor might help. Its the exact opposite of the Performance governor thus it will lock the maximum frequency on the lowest possible. It will always be the best choice in terms of power saving.

 

Thats all? Pretty bad for Linux...

Of course thats not the whole story. In fact you might have already thought of a governor yourself while you read those lines. A governor which combines the best of both worlds. Here it gets interesting. The very official solution is called the Ondemand Governor. I don't want to go to much into detail about this one, because its much more complex than the above ones. Ondemand scales the frequency according to the current usage of the system and provides performance when its needed as well as saves power when nothing needs to be done (thats the reason behind the name). Its a much more efficient approach. There are other governors as well in the current mainstream Linux kernel. Conservative and Userspace are some examples (the latter one shifts the frequency management directly into userspace) and of course there are a bunch of device specific ones.

 

Whats the best governor for my android phone?

Its simple; there is no "best" governor choice available. This answer depends really hard on your usage, some governors might be better for your usage profile while others won't help. However, many kernel developers implement kind of "marketing" governors. Those governors might have names such as Smartass, Lazy, Lionheart or Ondemandx. Such governors are based upon the already named and according to their developers they seem to make some magic voodoo things happen. I don't like such governors in general because they are mainly buzzwords, but as long as a governor gets regularly updates and patches they have a chance to get some day merged into the mainline kernel. Its rather important that your device maintainer/developer focus on one or two governors. The Interactive Governor from Google is a good example for an outside the mainline kernel governor. Its especially designed for mobile phones and has the advantage of its low latency design. This means it can react very fast to changed workloads. Another popular choice is the well-known Ondemand governor which has the benefit of upstream support. 

Furthermore you can tweak a already running governor if you don't want to change your governor.

cd /sys/devices/system/cpu/cpufreq/

This path leads to the governor specific parameters (if a governor supports them). You've got plenty of tunables here. I won't go into any further detail, thats up to another article!

 

Scaling is the key

When we want to make a governor more efficient, we have to simply scale better. The Ondemand Governor has the benefit that it runs great, on every single machine! Meaning even your Linux powered Toaster should scale perfectly as well as your companies mainframe system. Thats a huge responsibility for such a small subsystem. Optimizing a governor for a mobile phone is rather simple. We just have to learn from ourselves how we actually use our phones and thats an easy task. In general, we should drop the frequency to the lowest when there is no screen interaction or when we just put the phone back into our pocket. When we play some games or do some work intensive stuff we should raise the frequency but not for too long (to save the juice of our battery). Sounds easy? Its much more complex from a programmatic point of view.

In the end, scaling matters and is the key to optimize this little driver for our personal needs. On most systems the CPU is the most consuming component after the screen and the radio.

 

The future of governors

So lets talk about a possible future of the governors. They work well at their current stage, but could the kernel do it better? The answer is yes. Most governors are load-based governors, which means they need the actual system load from another subsystem of the kernel. There is one system inside the kernel, which knows better than any other system what's really happening right now in the entire OS. Its called the scheduler. If you think outside the box it should be obvious that this frequency management should be done by the scheduler itself, because no other system knows more about processes and threads and their lifecycles than this one.