Slideshare.net (beta)

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

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

Slide 3: 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! 3

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

Slide 5: 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 Full speed Half speed 5

Slide 6: 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 6

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

Slide 8: 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 8

Slide 9: 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 9

Slide 10: 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 10

Slide 11: 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: 0.0s 1.0s • Grouping timers system wide can improve this: 0.0s 1.0s 11

Slide 12: 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 12

Slide 13: 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) 13

Slide 14: 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! 14

Slide 15: 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 15

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

Slide 17: Tools: PowerTOP, strace 17

Slide 18: Tools: PowerTOP, strace 18

Slide 19: 19

Slide 21: 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 21

Slide 22: C states C state Power Latency C0 34 W / 25 W C1 13.5 W 0 C2 12.9 W 10us C3 7.7 W 85us C4/C5 1.2 W 185us −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 22

Slide 23: 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 23

Slide 24: 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 24