Managing device power with an operating system

Device power issues are becoming increasingly important. It is widely recognized that this is no longer simply a hardware matter – software has an increasing impact on power consumption. The selection of an operating system (OS) may be governed by many factors; consideration of power management is an important matter. This article reviews the various aspects of an OS that can affect its influence on power consumption and offers guidelines to avoid pitfalls.

Operating systems’ influence on power consumption
The choice of OS influences the power consumption of an embedded system in two separate and distinct ways. First, there is active power management, where the OS takes specific action to control, limit, or optimize the device power consumption. Second, there is the passive influence on power consumption, where architectural features of the OS have an indirect (and probably unintended) effect on power consumption.

Active power management
There are an increasing opportunities for software to positively influence device power consumption. This is logical, as the software “knows” what is expected from a device at any given moment in time, in terms of functionality, speed, etc. It is logical that this power management capability be accommodated in the OS. There are three well defined areas where power may be managed by software:

  • selective switching off of logic blocks (peripherals) when they are not required
  • management of the clock frequency and supply voltage of the CPU; this is Dynamic Voltage and Frequency Scaling (DVFS)
  • utilization of CPU low power modes

Peripheral power down
Many embedded systems have numerous peripherals, many of which are unused for much of the time. Examples might be Bluetooth and WiFi interfaces, displays, etc. If the software is provided with the means to switch off unused logic blocks, only reactivating them when they are actually needed, there is a lot of scope for power saving.

Dynamic voltage and frequency scaling
It is probably not intuitive to the average software engineer – though experienced embedded developers may have more hardware insight – that the power used by a system is increased with rising clock frequency. In a way, this is unsurprising, as clearly more work can be done in a given time period by a CPU that is executing faster.

It is increasingly common for systems to incorporate DVFS, which enables the software to adjust the CPU clock frequency. It makes sense that there are many times when all the available computing power is simply not needed, and a low frequency, which results in lower power consumption, would suffice.

Low power CPU modes
Increasingly, processors designed for embedded applications feature a number of low-power modes that, under the control of software, may be entered when circumstances allow. The details of these different modes and the terminology is far from standardized, but here are two typical examples that address the needs of many applications:

  • Suspend is when the CPU and all peripheral devices are powered down, but power to memory is retained to preserve its content. This mode continues to consume some power (to keep the memory alive) and allows processing to resume with minimal delay.
  • Hibernate allows a much longer period of inactivity. Memory contents are written to persistent storage (typically flash memory) and everything is powered down. This mode consumes almost no power at all, but there is a delay resuming operations when the memory is reinstated.

Care is needed in applying low power modes, as they all have a cost. Extra code is executed to enter and exit any of these modes and this consumes a certain amount of power. Clearly the power saved by using the mode must exceed that consumed to deploy it.

A power management framework
It is logical for the operating system to be given responsibility for power management, as it has a supervisory capacity over the application code. Ideally a power management framework is provided, which enables centralization of the power management operations.
A key requirement is for device drivers to be able to register their requirements with respect to power management. For example:

  • which peripheral blocks need to be powered
  • which CPU frequency (or frequencies) are acceptable
  • DMA requirements

Power management is normally modeled using the concept of ‘operating points’, which are a series of voltage/frequency settings.Passive effects of an OS on power consumption
As we haveshown, software can take an active role in managing power consumption,but another, more simplistic parameter is the selection of operatingsystem.

A traditional real-time operating system (RTOS) is likelyto have a significantly smaller memory footprint than Linux, so lessmemory needs to be fitted. As memory consumes power, less memory meansless power consumption. This argument is sound, but may be countered bythe assertion that memory power consumption is really not too bad.However, it is obvious that a larger OS has more code and execution ofmore instructions results in the consumption of more power. It may beassumed that the amount of power the CPU consumes, when doing aparticular job, will vary depending upon the OS. But this needs to beproven by experiment.

A colleague of mine performed such anexperiment using a media player device. It was decoding an MP3 of a 71db220Hz sine wave. He ran the code twice: the first time executing theapplication under an RTOS (he used Mentor’s Nucleus for the test), thesecond using Linux. The power consumed was measured and plotted overtime.

As shown in the plot in Figure 1 , power consumed bythe Nucleus RTOS is shown in pink; Linux is dark blue. The results areinteresting: when running Linux the CPU was consuming nearly 25% morepower than when it was doing the exact same job under Nucleus.

Figure 1: Comparison of power consumer between the Nucleus RTOS (pink) and the Linux operating system (dark blue)

Thereis also an increase in power consumption of another 20% between about3000 and 4000 on the plot when running Linux. What caused this? We donot know. Obviously Linux was doing something in this time frame thataffected it CPU load.

This experiment set out to see whether aconventional RTOS really did benefit a design in terms of powerconsumption. We used Mentor’s Nucleus for the test, which succeeded inthis goal. It also demonstrated the non-real-time (i.e., unpredictable)behavior of Linux, which may be a problem for certain applications.

Conclusions
Fora power sensitive embedded application, the selection of OS iscritical. First, the availability of active power management facilitiesis a must. Second, the size and performance (efficiency) of the OS andits impact on power consumption must be considered.

Colin Walls has over thirty years experience in the electronics industry, largelydedicated to embedded software. A frequent presenter at conferences andseminars and author of numerous technical articles and two books onembedded software, Colin is an embedded software technologist withMentor Embedded [the Mentor Graphics Embedded Software Division], and isbased in the UK. His regular blog is located at blogs.mentor.com/colinwalls . He may be reached by email at colin_walls@mentor.com .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.