Android overclocking: Governors explained

If you’re running a rooted Android device or even a HP TouchPad with Preware you may have been tempted to try a little overclocking and come across Governor settings. On tablets and smartphones it’s not hard and as long you don’t go crazy, which is usually impossible, it’s perfectly safe. We’re not going to go into the details of Android overclocking here but we are going to take a quick look at one of the less-well explained areas. An option called the Governor.

In days of the steam engine a governor was a device that controlled the overall speed of how fast the engine would run. Usually in the form of two weighted brass balls. A governor in Linux and with Android tablets or smartphones does exactly the same thing, it’s a control system that mediates how fast the processor should run. IBM has an extensive run down of how the standard governors control speed, and we’ll break these down below.

Basically it a bit of code that controls how the kernel responses to processor demands from the system. It can ignore them, it can run the processor constantly at full speed, it can respond in a delayed fashion or in an instant. A number of basic default ones are usually available with a couple of custom options commonly found in Android builds.

Performance

Constantly runs the processor at its full speed and so is a governor that should be avoided. Possibly of use for benchmarking or demanding tasks that require instant response.

Powersave

Constantly runs the processor at its slowest speed. While technically this sounds like it would save power in practise it doesn’t, as it takes so much longer to complete tasks the CPU cannot fall into sleep states where it truly saves power.

Ondemand

Dynamically changes CPU frequency in response to CPU utilization. Probably the best balanced governor to choose as it selects the highest available processor frequency when the processor load rises above a definable threshold (up_threshold). Could create an amount of latency.

Conservative

A more aggressive version of the Ondemand governor that would be a better choice for more demanding tasks, as it’s responds more quickly in meeting increases in CPU demand and keeps the speed rating higher for longer, at the price of battery life.

Userspace

Use the userspace governor if you want to impose a unique power policy that is not provided by other kernel governors or if you want to experiment with directly setting different power policies.

Interactive

This uses an alternative approach to sampling CPU demand at a set rate. It uses a fixed timer that if the CPU is 100% busy when it fires, continues to ramp the CPU speed to the maximum setting. If it’s not the speed is ramped down based on recent measured demand.

SmartAss (v2)

Available with a number of kernels but doesn’t have any official description beyond being an improved variant of the Interactive governor. It’s the one we tend to opt for.