Programming for Low Power: It's everyone's responsibility Arjan van de Ven Software and Solutions Group July 25th, 2007

The next 45 minutes Some concepts behind power How software is ruining your power consumption Tools to help you diagnose

Some concepts behind power

How software is ruining your power consumption

Tools to help you diagnose

Why software matters for power It’s the hardware that consumes the power after all, right? Hardware can scale its power consumption down … … . but software needs to allow for this A single, misbehaving, application can destroy any power savings the hardware can do!

It’s the hardware that consumes the power after all, right?

Hardware can scale its power consumption down …

… . but software needs to allow for this

A single, misbehaving, application can destroy any power savings the hardware can do!

What consumes power in a PC Lamps Radios Analog bits Processor Executing code Transitions Memory

Lamps

Radios

Analog bits

Processor

Executing code

Transitions

Memory

Race-to-idle Save power by running at the highest speed Example: CPU that consumes 34 Watts at full speed, 24 Watts at half speed and 1 Watts when idle MP3 decoding that takes ½ second at half speed for a second of audio, ¼ second at full speed Half speed Full speed

Example:

CPU that consumes 34 Watts at full speed, 24 Watts at half speed and 1 Watts when idle

MP3 decoding that takes ½ second at half speed for a second of audio, ¼ second at full speed

Race-to-idle Save power by running at the highest speed At half speed, energy consumption is E = 0.5s * 24W + 0.5s * 1W = 12.5 Joules At full speed, energy consumption is E = 0.25s * 34W + 0.75s * 1W = 9.25 Joules Lesson: Do things as fast as you can so that the system can be idle longer

At half speed, energy consumption is

E = 0.5s * 24W + 0.5s * 1W = 12.5 Joules

At full speed, energy consumption is

E = 0.25s * 34W + 0.75s * 1W = 9.25 Joules

Sleep duty cycle It matters how frequently you go in and out of idle Ideal Reality = !=

It matters how frequently you go in and out of idle

Ideal

Reality

Sleep duty cycle It matters how frequently you go in and out of idle != Lesson: Stay in idle for long periods of time Avoid interrupting idle as much as possible

It matters how frequently you go in and out of idle

Software spoils the game Depending on the exact model, a processor wants idle periods of at least 20ms to 50ms for it's power saving to work well The Linux kernel (prior to 2.6.21) wakes up from idle 250 or 1000 times per second Tickless idle to the rescue; eliminates most of these wakeups On a standard Linux desktop, userspace software easily wakes the processor from idle 400 or more times per second Current software is misbehaving and wasting power

Depending on the exact model, a processor wants idle periods of at least 20ms to 50ms for it's power saving to work well

The Linux kernel (prior to 2.6.21) wakes up from idle 250 or 1000 times per second

Tickless idle to the rescue; eliminates most of these wakeups

On a standard Linux desktop, userspace software easily wakes the processor from idle 400 or more times per second

Enemy #1: Polling Applications have been polling for checking if the mouse moved .. once per second (gnome-screensaver) checking if the sound volume changed .. 10 times per second (mixer applet) checking if it's time to show the next minute in the clock .. once per second (clock applet) checking if someone forgot to notify for a condition variable change .. 10 times per second (firefox) checking if something got put on an internal queue .. 30 times per second (gamin) or 10 times per second (evolution) checking to see if a smartcard reader got inserted on USB ... 10 times per second (gdm-daemon) checking if there is data on a pipe .. 10000 times per second (gksu) waking up 200 times per second (Macromedia Flash plugin) .... Needless to say that this is not good programming practice Frequent polling causes spattergroit

Applications have been polling for

checking if the mouse moved .. once per second (gnome-screensaver)

checking if the sound volume changed .. 10 times per second (mixer applet)

checking if it's time to show the next minute in the clock .. once per second (clock applet)

checking if someone forgot to notify for a condition variable change .. 10 times per second (firefox)

checking if something got put on an internal queue .. 30 times per second (gamin) or 10 times per second (evolution)

checking to see if a smartcard reader got inserted on USB ... 10 times per second (gdm-daemon)

checking if there is data on a pipe .. 10000 times per second (gksu)

waking up 200 times per second (Macromedia Flash plugin)

....

Needless to say that this is not good programming practice

Enemy #2: Timers Even after removing all the stupid polling, there are situations where you need to do a housekeeping task in the future Problem: on a system there are many programs needing this, resulting the following wakeup pattern: Grouping timers system wide can improve this:

Even after removing all the stupid polling, there are situations where you need to do a housekeeping task in the future

Problem: on a system there are many programs needing this, resulting the following wakeup pattern:

Grouping timers system wide can improve this:

Enemy #2: Timers In userspace: use g_timeout_add_seconds() for glib applications In kernel space: use round_jiffies() and round_jiffies_relative() Consideration: if the entire internet hits your server at the start of each second... it will die. Diversity is good. Group timer events system wide but not internet wide

In userspace:

use g_timeout_add_seconds() for glib applications

In kernel space:

use round_jiffies() and round_jiffies_relative()

Consideration:

if the entire internet hits your server at the start of each second... it will die. Diversity is good.

Enemy #3: Disk IO Disks and CDs are moving, analog parts They consume a lot of power when in use High speed links (SATA) consume lots of power Except when in power-save mode (idle) Besides the obvious, some things cause disk IO that you might not expect: Opening files that are in cache (atime update) use O_NOATIME flag to the open() call if possible Looking for files or directories that do not exist even when using GAMIN (or INOTIFY)

Disks and CDs are moving, analog parts

They consume a lot of power when in use

High speed links (SATA) consume lots of power

Except when in power-save mode (idle)

Besides the obvious, some things cause disk IO that you might not expect:

Opening files that are in cache (atime update)

use O_NOATIME flag to the open() call if possible

Looking for files or directories that do not exist

even when using GAMIN (or INOTIFY)

Java / C# / Python / Ruby / ... High level languages give quick results.... ... but sometimes the semantics get implemented with frequent polling! Some language primitives are implemented badly pick a different JVM ? Don't use the primitive Evaluate your runtime language environment before deciding to use it!

High level languages give quick results....

... but sometimes the semantics get implemented with frequent polling!

Some language primitives are implemented badly

pick a different JVM ?

Don't use the primitive

Evaluate your runtime language environment before deciding to use it!

Special case: Media playback For DVD playback: Don't spin up the CD all the time For audio playback: Don't spin up the harddisk all the time For both: decode in larger batches (so you can be idle longer) Pick a large buffer size default Large enough for a minute of audio or 20 minutes of video Use large buffers for multimedia

For DVD playback: Don't spin up the CD all the time

For audio playback: Don't spin up the harddisk all the time

For both: decode in larger batches (so you can be idle longer)

Pick a large buffer size default

Large enough for a minute of audio or 20 minutes of video

Tools: PowerTOP and strace Informative: run "strace" on your program When it's idle.. is it really? Don't forget threads!

Informative: run "strace" on your program

When it's idle.. is it really?

Don't forget threads!

Tools: PowerTOP, strace

Tools: PowerTOP, strace

C/P/T states CPUs have 2 states: Executing instructions Not executing instructions (idle) P-states determine how fast (what frequency) the processor executes instructions C-states determine how deep the processor can sleep when not executing instructions T-states are the emergency brake to forcefully reduce execution speed to prevent overheating

CPUs have 2 states:

Executing instructions

Not executing instructions (idle)

P-states determine how fast (what frequency) the processor executes instructions

C-states determine how deep the processor can sleep when not executing instructions

T-states are the emergency brake to forcefully reduce execution speed to prevent overheating

C states Deeper C-states have a longer latency to wake up Functionality restriction: C3 and deeper turn of cache-snooping Result: The CPU wakes up on any DMA bus master activity Current CPUs don’t wake up entirely: C2-popup Frequent DMA will prevent the use of C3 and deeper USB 185us 1.2 W C4/C5 85us 7.7 W C3 10us 12.9 W C2 0 13.5 W C1 34 W / 25 W C0 Latency Power C state

Deeper C-states have a longer latency to wake up

Functionality restriction: C3 and deeper turn of cache-snooping

Result: The CPU wakes up on any DMA bus master activity

Current CPUs don’t wake up entirely: C2-popup

Frequent DMA will prevent the use of C3 and deeper

USB

P states P-states control the frequency and voltage of the processor Frequency saves only a little power Voltage is the key factor (P goes with V^2) Intel processors can switch very quickly (microseconds) Ondemand governor determines the best frequency in Linux

P-states control the frequency and voltage of the processor

Frequency saves only a little power

Voltage is the key factor (P goes with V^2)

Intel processors can switch very quickly (microseconds)

Ondemand governor determines the best frequency in Linux

T states T-states forcefully introduce idle cycles in the processor T-states do not control voltage! Idle cycles do not get into power saving C-states Avoid T-states whenever you can, they do not save energy

T-states forcefully introduce idle cycles in the processor

T-states do not control voltage!

Idle cycles do not get into power saving C-states

Avoid T-states whenever you can, they do not save energy