Your SlideShare is downloading. ×
Os Vandeven
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Os Vandeven

1,977
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,977
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Programming for Low Power: It's everyone's responsibility Arjan van de Ven Software and Solutions Group July 25th, 2007
  • 2. The next 45 minutes
    • Some concepts behind power
    • How software is ruining your power consumption
    • Tools to help you diagnose
  • 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!
  • 4. What consumes power in a PC
    • Lamps
    • Radios
    • Analog bits
    • Processor
      • Executing code
      • Transitions
    • Memory
  • 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
    Half speed Full speed
  • 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
  • 7. Sleep duty cycle
    • It matters how frequently you go in and out of idle
    • Ideal
    • Reality
    = !=
  • 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
  • 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
  • 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
  • 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:
    • Grouping timers system wide can improve this:
  • 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
  • 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)
  • 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!
  • 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
  • 16. Tools: PowerTOP and strace
    • Informative: run "strace" on your program
      • When it's idle.. is it really?
    • Don't forget threads!
  • 17. Tools: PowerTOP, strace
  • 18. Tools: PowerTOP, strace
  • 19.  
  • 20.  
  • 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
  • 22. 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
  • 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
  • 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