One of the most important (and obvious) characteristics of mobile computing is that mobile devices use batteries rather than being plugged into the mains power. This means that every part of a mobile system needs to be tuned to save as much power as possible yet while offering the best performance available. Normally these two demands (efficiency and performance) are at odds with each other. The higher the performance, the higher the power consumption and heat generated. On the desktop this isn’t so much of a problem as PCs are connected to the mains and have massive cooling fans. However that isn’t the case on mobile.
There is a direct relationship between the amount of power used by a processor and its clock frequency. In a nutshell the quicker all the transistors (gates) are switched in the chip the more power is used. How often the gates are switched is controlled by the clock frequency. You can maybe think of it as akin to the engine revs in a car, the higher the revs the more fuel consumed.
What this means is that by lowering the clock frequency the power consumption is also lowered, and that is vital for mobile computing and especially for smartphones. There is a feature in Android (via the Linux kernel) which allows the clock frequency of the processor to be varied, scaled down when the phone is not being used much and ramped up when needed.
It turns out that when the clock frequency is lower then the chip doesn’t need as many volts to run. So there is a correlation between the clock frequency and the volts needed. Therefore these two can be adjusted in tandem. Whenever the clock frequency is changed then the voltage can be changed as well. Altering them together is known as Dynamic Voltage and Frequency Scaling or DVFS for short.
What does it mean for users?
The biggest benefit for smartphone users is battery life. Since the CPU isn’t running at full power all of the time it means that while you are reading a web page or pondering your next move in a game then the CPU frequency can be scaled down to save power. Once the app needs more performance then the CPU frequency (along with the voltage) will be increased to handle the new demands. However this does show one weakness of DVFS, it is reactive. The frequency is increased as a reaction to the demand for more performance. This means that there is always a slight delay from when the extra performance is needed to when it is delivered. Thankfully that delay is almost imperceptible, however developers using profiling tools might see it, but more about that in the section below. To get around this lag, Android has one little trick, whenever the screen is touched the CPU frequency of one or more cores is boosted in anticipation of some user interface activity.
If you want to see DVFS in action then you can download an app like CPU Z. On the SoC tab you can see lots of information about your device’s processor including the make, model and number of cores. Also listed is some clock speed data. Each core is listed besides its current frequency. If you watch closely then you will see that each core has a changing clock speed. If some of the cores are stopped and the others are running at a low speed (like 300MHz or similar) then touch the screen to see how the cores react.
There is one more thing worth mentioning, the scaling governor. There is component of the Linux kernel which controls the DVFS scaling. It is called the scaling governor. The default governor is called “interactive.” It is in fact the interactive governor which ramps up the CPU frequency when the screen is touched. If you have rooted your phone it is possible to change the governor using programs like Kernel Adiutor (ROOT) or Root Booster.
There is lots of information (and sometimes, misinformation) about changing the governor to get significantly different performance/battery results from your device. If this kind of thing interests you then you could have some fun playing with the governor settings, however you can only change the governor if you have root access. It is also worth remembering that smartphone OEMs spend a lot of time and money building phones with the highest possible performance levels while maintaining a reasonable battery life. If tweaking the governor actually produced better results then you can be sure that the OEMs would do that.
What does it mean for developers?
I mentioned that the CPU scaling is reactive and not proactive. This means that there can be a lag when exiting a low frequency state of around 20 ms. If you use Android System Trace (Systrace) for profiling your apps then you can sometimes see that the first frame may not render in the 16ms time frame needed for 60 frames per second. There isn’t much that you can do about this as a developer, however knowing that this is the expected behavior will stop you chasing your tail if you see a dropped frame when coming out of a low CPU frequency.
Colt McAnlis has a brief video about “CPU Frequency Scaling” on Android. In the video he discusses how DVFS is one of those harsh realities of mobile development that you can’t control, but can have an impact on your app.
There is more…
In the last few years there have also been a number of other advances to help improve battery efficiency while boosting performance. The most important of which is probably Heterogeneous Multi-Processing (HMP) as used in ARM’s big.LITTLE system. In a HMP processor not all the cores are equal (hence Heterogeneous). In a modern 64-bit processor this would mean that a cluster of Cortex-A57 or Cortex-A72 cores would be used in conjunction with a cluster of Cortex-A53 cores. The A72 is a high performance core, while the A53 has greater energy efficiency.
What this means is that when the workload becomes too much for the LITTLE cores (Cortex-A53 in this example) then the big cores (Cortex-A72) take over. If DVFS is akin to the revs of a car engine, the big.LITTLE is like changing gears.
I have written about and benchmarked big.LITTLE processors quite extensively, if you want to know more about HMP then I can suggest the following articles: Fact or Fiction: Android apps only use one CPU core, Up close and personal: how the Samsung Galaxy S6 uses its octa-core processor, and Exynos 7420: Multitasking, multi-core and multiprocessing.
The initial implementations of the software part for big.LITTLE used the DVFS system to trigger a switch from the LITTLE cores to the big cores. Since then things have become more complex and ARM is currently working on an energy-aware scheduler for Android which will allow the Linux kernel to pick which cores run which tasks based not only on the feedback from the DVFS system but also from the Intelligent Power Allocation (IPA) algorithms and from CPU idle. There are more details in my article Energy-Aware Scheduling for Android.
So bottom line, CPU frequency scaling is good, it saves battery. When coupled with big.LITTLE, IPA and energy-aware scheduling then the battery savings are even greater.