• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Os Vandeven
 

Os Vandeven

on

  • 2,644 views

 

Statistics

Views

Total Views
2,644
Views on SlideShare
2,644
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Os Vandeven Os Vandeven Presentation Transcript

    • 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
    • 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!
    • What consumes power in a PC
      • 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
    • 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
    • Sleep duty cycle
      • 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
    • 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
    • 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
    • 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:
    • 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
    • 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)
    • 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!
    • 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
    • Tools: PowerTOP and strace
      • 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
    • 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
    • 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
    • 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