DipartimentidiElettronicaedInformazione

PolitecnicodiMilano

PatrickBellasi
bellasi@elet.polimi.it

LinuxPowerManagement
Architecture
AnupdatedreviewonLinuxPM
frameworks

Lastupdate:Jan10,2009

PatrickBellasibellasi@elet.polimi.it

Agenda

Outlinethearchitectureforadvancedpowermanagement
supportinrecentLinuxkernels
keypointsforeffectivePMandoverallpictureview

Reviewofmainsubsystems

Advancedtimekeepingframework
Clockframework
Voltage/PowercontrolFramework
QoSFramework
CPUIdle
CPUFreq
LinuxPM

Whyweneedthem?
Whattheydo?
Howwecanexploitthem?

PatrickBellasibellasi@elet.polimi.it

ModernPMarchitectures
Keypointsforeffectivepowermanagement

Exploitpartialactivity
disablepartsofthesystemwhennotneeded

SWdoespartofthework,HWdependenciesdotherest
exploitexistingsystemframework

trackdependencies(producerconsumer)
trackusage(referencecounting)
systemconstraintsassertion
notificationchains

Finegrainedtracking
andconstraints

driverssupportrequired
aggressivelygetandreleaseresources
supportefficientlyOFFmode(0volts)

fullcontextloss,lowlatencywakeup,
providecontextsavingrestoreroutines

useconstraintstorequireoperationalrestrictions

PatrickBellasibellasi@elet.polimi.it

ModernPMarchitectures
Keypointsforeffectivepowermanagement

Controlpowersources
clocks,powerdomains,voltagedomains,memoriesandpowerIC
resources
devicedriversshouldexploitinterfacestocontrolpowerresources

Constraintsawaredriversandsubsystems
Inactivestate
powersavinginOSidle

automaticchoicebetweenmultipleCStates

OFFandretentionmodes

manualsuspend/resume
systemwidesleepstates

Activestate

dynamicpowermanagement

automaticchoicebetweenmultiplePStates

PatrickBellasibellasi@elet.polimi.it

ModernPMarchitectures
whatweshould(already)have
Legend
ArchIndep
ArchDependant

MMResourceManager

User
Kernel
LDM

OMAP34xx
Control
Notifications
Constraints

DSPBridge

CPUIdleGoevernor
(menugovernor)

CPUFreqGoevernor
(ondemandgovernor)

CPUIdleFramework

CPUFreqFramework

Policymanagement
Layer

ConstraintsFramework
DSPBridge

CPUIdleDriver

Drivers

Workload
Predictor

DeviceDriver
Layer

CPUFreqDriver

ResourceTracking
Layer

ResourceTracking

DPLLCon

OPPCon

Frequ.Con

LatencyCon

MemoryLogic

Voltage
Framework

DPLLState

PWRM

Powerdomain

Workload
Predictor

Clock
Framework

Logical

SharedResourceFramework

PowerResource
Management
Layer

DSPBridge
PRCMAPI
Layer2

PRCMAPILayer1

SmartRelfex
Driver
PowerIC
Driver

PRCMAPI
Layer1&2
(OMAP34xx)

PatrickBellasibellasi@elet.polimi.it

LinuxframeworkstosupportPM
Introduction

TypicalmainlineLinuxPowerManagementfeatures:
Platformspecificcode

idleloop,timekeeping(dynamictick)&clocktree,latency

DynamicPowerManagement

Lowpowerstatesactivationforunuseddevices
CStates,LDM,Suspension(RAM),Hibernation(Disk)

DynamicVoltageandFrequencyScaling
Adaptingdeviceperformancestoapplicationneeds
PStates,OPP

Mainfocusonx86arch

customanddifferentPMdevelopmentforSoCembeddeddevices
2ndLinuxPMSummitwasonlyon2007
increasingemphasisonembeddedsystems

oo
d

2.6.24

e
fra
m
ew

2.6.25

eg
ul
at
or
s
Fr
am
ew

or
k

or
Q
k
oS
F
ra
m
ew
or
k

C
PU
Id
l

G
en
er
ic
T
H
im
rti
e
m
of
er
D
s
C

ay
b
lo
ck ase
S

ou cod
G
e
rc
en
e
er
a
nd
C icD
C
lo
lo
ck yna
ck
fr
m
E
a
i
c
m
D
ve
T
yn
ew
ic
nt
tic
k

or
ks
k

C
G PU
ov Fr
er eq
no O
r
nD
em
an
d

Timeline

Li
am
G
rid
w

G
ro
ss

2.6.21

M
ar
k

lip
ad
i

2.6.16

Ve
nk
at
es
h
Pa
l

2.6.9

In
go
M
ol
na
Th
r
om
as
G
le
ix
ne
r

tz

lip
ad
i

Jo
hn
S
tu
l

Ve
nk
at
es
h
Pa
l

PatrickBellasibellasi@elet.polimi.it

LinuxframeworkstosupportPM
7

April2008

2.6.27

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem
Theoldtickbasedimplementation

Priorto2.6.16

8
Stronglyassociatedwith
individualHWdevices

Arch1

Lakeofageneric
abstractionlayer

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

Arch2

Timekeeping
Tick

Processacc.
Clockrelated
services

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

Arch3

Profiling
Jiffies
Timerwhell

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

Timetrackedusing
periodictimerticks

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem
Towardsanewimplementation

Requiredabstractions
Clocksource(CS)management

providereadaccesstomonotonicallyincreasingtimevalues
usehumanorientedvalues(nanoseconds)

Clocksynchronization

systemtimevalueandclocksourcedriftscorrection
usereferencetimesources(e.g.NTPorGPS/GSM)

Timeofdayrepresentation

applyingdriftscorrectionstoclocksource

Clockeventdevice(CED)management

schedulenexteventinterruptusingclockeventdevice
minimizearchdependentcode,alloweasyruntimeadditionofnewCED

Removingtickdependencies

bettersupporthighresolutiontimersandprecisetimerscheduling
byreplacetheCTW(CascadingTimerWheel)mechanism

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem
hrtimersacomplementarytimesubsystem

WhyanewTimerSubsystem?
CTW(1997)hasunacceptableworstcaseperformances

InsertionisO(1),butcascadingrequireinterruptdisabling...
CTWisthebettersolutionforlongtermprotocoltimeoutrelated
timers:

expirationtimewithinthefirstcategory
removedbeforetheyexpireorhavetobecascaded

isbasedonperiodicinterrupt(jiffies)
supportonlylowresolutiontimevalues

10

Proposesolution:usetwocategoryfortimers
Timeoutslowresolution,almostalwaysremoved

usingtheexistingCTW

Timershighresolution,usuallyexpire
usingthenewhrtimersframework,basedonhumantimeunits[ns],kept
inperCPUtimesortedlistimplementedusingredblacktree(O(log(N))

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem
hrtimersacomplementarytimesubsystem

11

Since2.6.16
Arch1

Usinghumanbased
timeunits[ns]

Betterdatastructurestosupport
othertimercoderework
(e.g.highresolutiontimersand
dynamictick)

Timekeeping
Tick

Processacc.

Lowresolutionjiffies
basedtimers

Clocksource

HW

ISR

Clockeventdevice

HW

Arch2

hrtimers

Timerqueuesrunfromthe
normaltimersoftirq

TOD

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

Arch3

Profiling
Jiffies
Timerwhell

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem[5]
TheGenericTimeofDay(GTOD)

WhyaGenericTimeofDayImplementation?
allowsharingofclocksourcecodeacrossarchs

movelargeportionofcodeoutofarchspecificareas
limitarchdependentcodetoHWinterfaceandsetup

avoidinterpolationbasedcomputationofhumantimevalues

compensateclockdriftsasclocksourceoffsetstogetTOD
previousimplementationtrackcompensatedTODdirectlyandderive
increasinghumantimevaluesfromit(erroradditionproblem)

12

Proposedsolution:anewgenericTODframework

presentedbyJohnStultzatOLS2005,mergedin2.6.16

cleanupandsimplifybyarchindependentcommoncode
usenanosecondsasfundamentaltimeunit
modulardesignsupportingruntimeadd/removeoftimesource
breaktickbaseddependencytoavoidinterpolationissues

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem
TheGenericTimeofDay(GTOD)
Archindependentanddynamic
clocksourcemanagement

SharedHW

13

Humanbasedtimeunits
timeofdayrepresentation

ClockSource
Archdependentcodelimited
todirectHWinterfaceand
setupprocedure

Clocksynch.

Arch2

hrtimers

Timekeeping
Tick

Processacc.

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

Arch3

Profiling
Jiffies
Timerwhell

TOD

Clocksource

HW

ISR

Clockeventdevice

HW

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem[6]
TheClockEventDeviceAbstraction

WhyaClockEventDeviceAbstraction?

provideanabstractionlevelfortimekeepingandtimerelated
activities
substantialreductioninarchdependentcode
supporteitherperiodicorindividualprogrammableevents
buildthebaseforagenericdynamictickimplementation

14

Proposedsolution:byThomasGleixner,mergedin2.6.21
Registrationinterface:runtimeconfigurationofclockeventdevice

propertybaseddefinition(e.g.capabilities,max/mindelta,mult/shift)
supportgenericinterruptsetupcode(i.e.callbackbasedhandlers)
supportforpowermanagement

Eventdistributioninterface:bindclockeventsrelatedservicesto
clockeventsources

classicaltimeservices(e.g.processaccounting,profiling,periodictick)
nexteventinterrupt(e.g.highresolutiontimers,dynamictick)

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem[6]
HighResolutionTimersSupport

Whyhighresolutiontimers?
exploitbrandnewtimesubsystemsreworks(GTOD,hrtimers)

requirejustarchindependentcodebymodifyinghrtimersframework

accuratedeliveryofhighresolutiontimers

15

Proposedsolution:

presentedbyThomasGleixneratOLS2006
switchtohighresolutionmodelateinthebootprocess

exploitingclocksourceandclockeventdevicedynamicregistration
ensurekernelcompatibilityonnonhighresolutionplatforms

supportnexteventschedulingandnexteventinterrupthandler

softirqbasedexecutionofhrtimerqueues,independentfromtickbound
callbacksfromnexteventhandler(withsomelimitations,e.g.for
nanosleep)
notificationtoclockeventdistributioncodeaboutperiodicinterval
expiration

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem[7]
TheDynamicTickSupport

WhyaTicklessKernel?
processorsarequitegoodaboutsavingpowerwhenidle

HWhassupporttoreduceleakageonidlestates

avoidprocessorwakeupswhennothingishappening
byturningofftheperiodtimertickwheninidlestate
lookingatthetimerqueuetoseewhenthenexttimerexpires

CPUIdlecanexploitthisinformation
intheabsenceofotherevents(e.g.hardwareinterrupts),thesystemwill
sleepuntilthenearesttimerisdue

enabletheperiodictickoncetheprocessorgoesoutoftheidlestate

16

Proposedsolution:mergedin2.6.21

roomforfurtherdevelopment(i.e.fullticklesssystems)

timesliceiscontrolledbythescheduler,variablefrequencyprofiling,and
acompleteremovalofjiffiesinthefuture

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem[8]
TheDynamicTickSupport

17

Nomadikstatus
supportfordisablingthetimertickduringidlewasfirst
mergedin2.6.6(2004,archs390)
weareusinganoldinterface,notthenewoneprovidedby
clocksourcedevices,but...

RussellKing(20080511,21:55:59GMT):

[ARM]RemoveobsoleteandunusedARMdynticksupport

dyntickissupersededbytheclocksource/clockeventinfrastructure,
usingtheNO_HZconfigurationoption.Nooneimplementsdyntick
onARManymore,soit'spointlesskeepingitaround.Remove
dynticksupport.

PatrickBellasibellasi@elet.polimi.it

TheLinuxTimeSystem
DeferrableTimers

18

Whydeferrabletimers?

betterexploitdynamictick,byallowingtosleeplonger
notalltimershastorunassoonastherequestedperiodhasexpired
noncriticaltimeoutscanrunsomefractionofasecondlater

i.e.whentheprocessorwakesupforotherreasons
Intr

250

500

[ms]

Proposedsolution:newfunctionaddedtotheinternal
kernelAPI

init_timer_deferrable(structtimer_list*timer)
timersdefinedasdeferrablearerecognizedbythekernel
willnotbeconsideredwhenthekernelmakesits"whenshouldthe
nexttimerinterruptbe?"decision
timer_list,workqueue,

PatrickBellasibellasi@elet.polimi.it

LinuxTimekeepingSubsystem
CompletesupportforRTandPM
SharedHW

19

ClockSource

Clocksynch.

hrtimers

TOD

Arch1

HW

Timekeeping
SharedHW

Clockevents

Nextevent

ISR

HW
Arch2

Dynamictick

HW
Eventdistribution
HW

Processacc.
Arch3

Profiling

HW
Jiffies
ISR
Timerwhell

HW

PatrickBellasibellasi@elet.polimi.it

TheClockFramework
centralizedcontrolforallclockrelated
functionalities

Definean(abstract)APIforallclockrelatedfunctionalities
dependencies(clocktree),rates(get/set),status(enable/disable)

Since2.6.16
standardopensourcesolution

InitiallyaddedforARM,nowmultiplearchitecturesuseit

In2.6.25:ARM(OMAP,PXA,SA1100,AT91,...),Avr32,PowerPC,...

recentproposalsonLKMLforagenericclockAPIimplementation

Usedbydevicedrivers
referencecounting
reentrantcode

20

Maysupportlayeredstructure

platformgenericlayerandboardspecificlowlevel

PatrickBellasibellasi@elet.polimi.it

TheClockFramework
centralizedcontrolforallclockrelated
functionalities

21

Nomadikstatus(2.6.24)
DummysupportjustforCLCDandUARTclocks
NotrackingforMainandSystemclock,USB,...

emptyget/setmethods,seemthatworkisinprogress...

CustomClockFrameworkforsettopboxes

PatrickBellasibellasi@elet.polimi.it

Power/VoltageFramework
trackdevice'spowerdependencies

provideaframeworkanaloguestotheclockframeworkbut
forpower/voltageregulatorscontrol
voltageregulatorsdependencytracking
satisfyclientdevicesneedsdependingontheirstate

optimizegeneratorsusageandefficiency

nosupportinmainline,butdifferentpatchsetavailable
ARMpatchbyNokia(notoomuchgeneral)
PlatformindependentframeworkbyWolfsonMicroelectronics

22

Nomadikstatus(2.6.24)

n*k15:limitedplatformpowerdomains
n*k30:muchmoreopportunities

PatrickBellasibellasi@elet.polimi.it

Power/VoltageFramework
WolfsonMicroelectronicsLinuxVoltageand
CurrentRegulatorFramework[2]

AnnouncedonLKMLinFeb2008,presentedonELC2008
Standardandgenerickernelinterfacestodynamicallycontrolvoltage
regulatorsandcurrentsinks

Betterexploitregulatorsdynamics
e.g.consumerwith10mAload:
100
70%@Normal=~13mA
90
90%@Sleep=~11mA
80

Saving~2mA

Efficiency(%)

23

idlemode

70

normalmode

60
50

40
30
20
10
0

10

100
Load(mA)

1000

PatrickBellasibellasi@elet.polimi.it

Power/VoltageFramework
WolfsonMicroelectronicsRealWorld
Examples

24

Somerealworldexamples:
CPUFreq:voltagecontrolmatchingoperatingfrequency
CPUIdle:voltagecontrolmatchingidlestate
LCDbacklighting:controlviawhiteLEDcurrentreduction
Audio:analogsupplycontrol,componentscontrol

FMTuner,SpeakerAmplifierwhenusingHeadphone

NAND&NOR:idlepowercontrol

e.g.R/W=35mA,Erase=40mA,Erase+R/W=55mA,Idle=1mA

PatrickBellasibellasi@elet.polimi.it

Power/VoltageFramework
WolfsonMicroelectronicsLinuxVoltageand
CurrentRegulatorFramework[2]

25

Fourseparateinterfaces
RegulatordriverAPI
Allowsregulatordriverstoregisterandprovideoperationstothecore
Notifiercallchainforpropagatingregulatoreventstoclients

Consumer(Client)driverAPI
completecontrolovertheirsupplyvoltageandcurrent
staticclients:onlyenable/disablesupport
dynamicclients:voltage/currentlimitcontrol

notifyclientV/Irequirementstoregulatordriver

PlatformAPI
creationofvoltage/currentdomains(withconstraints)foreachregulator
creationofaregulatortree

UserspaceAPI
exportsalotofusefulvoltage/current/opmodedatatouserspaceviasysfs
helpmonitordevicepowerconsumptionandstatus

PatrickBellasibellasi@elet.polimi.it

TheLatencyFramework
Explicitsystemwidelatencyexpectation
infrastructure

Latencyistheelapsingtimebetweenservicerequestand
servicedelivery
Couldinfluenceapplicationbehaviors
e.g.audiocodecDMAbufferrefill

26

Powersavingactionscouldinfluenceoverallsystem
latency
weshouldconsidertheirimpactonoverallsystemlatency

Needforasystemframeworkthattraceinstantaneous
latencyallowed

PatrickBellasibellasi@elet.polimi.it

TheLatencyFramework
Explicitsystemwidelatencyexpectation
infrastructure

27

include/linux/latency.h

Thesystemcantuneitsoperationstotheminimumlatency
requirementsineffectatthemoment
multipledriverscanannouncetheirmaximumaccepted
latency

driversknowdeviceoperatingmodesatanygivenmomentandthe
correspondingexpectedsystemresponsetime

collectandsummarizetheseexpectationsglobally

cumulatedresultcanbeusedbypowermanagementandsimilar
users
tomakedecisionsthathavetradeoffs

PatrickBellasibellasi@elet.polimi.it

TheLatencyFramework
Explicitsystemwidelatencyexpectation
infrastructure

Since2.6.19,aninterfacewheredriverscan:
announcethemaximumlatency[us]thattheycandealwith
modifythislatency
giveuptheirconstraint
afunctionwherethecodethatdecidesonpowersavingstrategy
canquerythecurrentglobaldesiredmaximum
anotifierchainallowinterestedsubsystemsknowwhenthe
maximumacceptablelatencyhaschanged

Currentlyusedbythegenericcpuidledriveronx86arch

28

Nomadikstatus(2.6.24)
notexploited:becausecpuidleisnotcorrectlyused?!
couldbeinterestingforsomestreamingdevices

Audio,Camera,WiFi,Bluetooth,CLCD,...

PatrickBellasibellasi@elet.polimi.it

TheLatencyFramework
Explicitsystemwidelatencyexpectation
infrastructure

29

Example:
user:idleloopcode

higherCstatesavesmorepower,buthasahigherexitlatency
idleloopcodeusetheseinformationstomakeagooddecisionwhich
Cstatetouse

announcer:audiodriver

knownsitwillgetaninterruptwhenthehardwarehas200usecof
samplesleftintheDMAbuffer
Registernotifier
setalatencyconstraintof,say,150usec
userinterface

LatencyFrameworkCore

IdleLoop

Announcerinterface

AudioDrv

...

Assertlatency
constraint

WiFiDrv
Updatelatency
constraint

PatrickBellasibellasi@elet.polimi.it

LatencyTOP
measuringandfixingLinuxlatency

toolforsoftwaredevelopers(bothkernelanduserspace),
identifyingwhereinthesystemlatencyishappening
whatkindofoperation/actioniscausingthelatencyto
happen
bothatsystemleveloronaperprocesslevel

focusesonthecases
theapplicationswanttorunandexecuteusefulcode,but
there'ssomeresourcethat'snotcurrentlyavailable(andthe
kernelthenblockstheprocess)

30

Kernelpatchneeded
keeptrackofwhathighleveloperationitisdoing
limitednumberofannotations
outputonprocfsorusingancursesbasedGUI

PatrickBellasibellasi@elet.polimi.it

LatencyTOP
measuringandfixingLinuxlatency

31

Here'ssomeoutputofLatencyTOP,collectedforamakej4ofa
kernelonaquadcoresystem

Cause
processfork
Readingfromfile
updatingatime
Lockingbufferhead
Writingtofile
Synchronousbufferheadread
WaitingforbufferIO

Cause
Writingtofile
Readingfromfile
WaitingforbufferIO
Lockingbufferhead
Unlinkingfile
EXT3(jbd)do_get_write_access
Filenamelookup

Maximum[msec]

1097.7
1097.0
850.4
433.1
381.8
318.5
298.8

Maximum[msec]
814.9
441.1
419.0
360.5
292.7
274.0
260.0

Average[msec]
2.5
0.1
60.1
94.3
0.6
16.3
7.8

Average[msec]
0.8
0.1
3.4
75.7
5.9
36.0
0.5

Withasmallchangeto
theEXT3journaling
layertofixapriority
inversionproblem

PatrickBellasibellasi@elet.polimi.it

QualityofServiceFramework[4]
thelatencyframeworkreloaded

linux/pm_qos_params.h

Kernelinfrastructuretoimplementacoordinationmechanism
tofacilitatecommunicationamongdevices(drivers),users
(applications)andsystem(powermanager)
deviceshavespecificpowermanagementcapabilities

devicestalkintermsoflatencies,timeouts,throughput
driverscouldbetteraddresspowermanagement
exposepowermanagementmechanisms

applicationshavespecificperformancesneeds

32

Since2.6.25

workonprogress,usedforiwl4965WiFidriveronx86

PatrickBellasibellasi@elet.polimi.it

QualityofServiceFramework
thelatencyframeworkreloaded

Provideinfrastructurefortheregistrationof:
Dependents:registertheirQoSneeds

e.g.

Watchers:keeptrackofthecurrentQoSneedsofthesystem

e.g.cpuidle,wifidrivers,...

3basicclassesofQoSparameter
latency[us],timeout[us],throughput[kbs]

platformcustomizableconstraintsset

Interruptlatency,powerdomainlatency,frequency/OPP

maintainlistsofpm_qosrequestsandaggregatedrequirements
kernelnotificationtreeforeachparameter

33

UsermodeinterfaceforrequestQoS

usingsimplechardevicenode

PatrickBellasibellasi@elet.polimi.it

TheCPUIdleFramework[1]
Donothing,efficiently...

Genericprocessoridlepowermanagementframework
supportformultipleidlestateswithdifferentcharacteristics

powerconsumptions,statepreservation,stateconstraints,entry/exit
latency

Supporttradeoffefficientlybetweenapplication
expectationsandidlestatepowersaving
Cleaninterface
abstractbetweenidledriverandidlegovernor

separatearchspecificidledriver(mechanisms)fromarchindependent
powermanagementgovernors(policies)

provideaconvenientuserspaceinterface

34

Since2.6.24

X86ACPI,forOMAPmappingtoACPIstates

PatrickBellasibellasi@elet.polimi.it

TheCPUIdleFramework[1]
Donothing,efficiently...

35

/sys/devices/system/cpu/cpuX/cpuidle

Userlevel
interfaces
governors

/sys/devices/system/cpu/cpuidle

Stepwise

Latencybased

ladder

menu

structcpuidle_governor{
init();
exit();
scan();
select();
reflect();
}

Decidethetarget
CState

governorinterface

GenericCPUIdleInfrastructure
driverinterface

drivers

acpicpuidle
ACPIdriver

cpuidlecore

halt_idle

datastructures
initializationandregistration
idlehandling
systemstatechangehandling

Populatesupported
CStates

structcpuidle_driver{
init();
exit();
redetect();
bm_check();
}

structcpuidle_state{
exit_latency;
power_usage;
target_residency;
usage;
time;
enter();
}
Implementfunctions
toenterCStates

[us]
[mW]
[us]
[us]

PatrickBellasibellasi@elet.polimi.it

TheCPUIdleFramework[1]
TheOMAP43xximplementation

ThefollowingCstatesaresupportedinCpuidledriver:
State

C0Systemexecutingcode

C1MPUWFI+Coreactive

C2MPUCSWR+Coreactive

C3MPUOFF+Coreactive
4000

C4MPUCSWR+CoreCSWR

C5MPUOFF+CoreCSWR
15000

C6MPUOFF+CoreOFF

latency[us]
residency[us]
0
0
20
30
100
300
3300

10000
11500

12000

20000

300000

Menugovernortakesthefollowingintoaccounttodecide
thetargetsleepstate:

36

Nexttimerexpiryinthesystem
Comparingtargetresidencywithavailablesleeptime
Comparingexitlatencywithsystemwidelatencyconstraints
Checkingforactivityinthecoredomain

Dynamictickbasedonsupportinkernel

PatrickBellasibellasi@elet.polimi.it

PowerTOP
measuringandfixingLinuxticklesssystems

identifyingwhatiscausingsystemwakeups
whatkindofoperation/actionpreventlongtimepermanenceinlow
powerconsumptionstates?
supportsoftwaredevelopers,bothkernelspaceanduserspace

mainfeatures
showhowwellyoursystemisusingvariousHWpowersaving
features

bothCandPStatesstatisticsarecollected

showyoutheculpritsoftwarecomponentsthatarepreventingoptimal
usageofyourHWpowersavings

userspaceshouldpreferedeferrabletimers

provideyouwithtuningsuggestionstoachievelowpower
consumption

37

supportforCPUIdlesincev1.10
previsouversionusedtheACPIinterface

PatrickBellasibellasi@elet.polimi.it

PowerTOP
examplesessionrunningonOMAP3430

38

PatrickBellasibellasi@elet.polimi.it

TheCPUFreqFramework[9]
CPUactivepowerconsumptionoptimization

Genericprocessoractivepowermanagementframework
supportformultipleperformancestateswithdifferentcharacteristics

powerconsumptions

Cleaninterface
abstractbetweendriverandgovernor

separatearchspecificcpudriver(mechanisms)fromarchindependent
powermanagementgovernors(policies)

provideaconvenientuserspaceinterface

39

Since2.6.9
ondemandgovernor

0.25s*34W+0.75s*1W=9.25J

Fullspeed 34
Halfspeed 24

scalingbasedonload
exploitracetoidle

[W]

Idle

0.5s*24W+0.5s*1W=12.5J

1
0

morerecentlyaddedsupportforconservativegovernor

implementingabetterbatteryfairpolicy

0.5

[s]

PatrickBellasibellasi@elet.polimi.it

CPUFreq
optimizedCPUpowerconsumptions

Userlevel
governors

powersaved

cpuspeed

aggressive

Inkernel
governors

40

structcpufreq_governor{
governor();
}

batteryfair

ondemand

userspace

conservative

governorinterface

GenericCPUFreqFramework
driverinterface

CPUspecific
drivers

Decidethetarget
PState

acpicpufreq

cpufreqcore

speedstep

ACPIprocessor
driver

datastructures
initializationandregistration
transitionhandling
policyandtransitionnotifiers

Definesupported
policyvalues

structcpufreq_driver{
init();
exit();
verify();
set_policy();
resume();
}

structcpufreq_policy{
min_freq;
[kHz]
max_freq;
[kHz]
transition_latency; [us]
...
}
Compilefrequency
tables

PatrickBellasibellasi@elet.polimi.it

LinuxPM
deviceruntimesuspend/resumesupport

Everydrivershouldimplementsuspend/resumecalls
registertotheLDM(LinuxDeviceModel)
releaseclocksandsavecontextinsuspendcallandrestore
thesewhenresumeiscalled
driverswhichhavealreadyreleasedtheirclocksandhave
savedtheircontextneednotdoanythingintheirsuspendcall

41

DriversshouldsupportOFFmodes

allregistersinthepowerdomainareresetwhenthepower
domaingoestoOFF
OFFmodecouldintroduceconsiderablelatencyforwakeup
thesystemcanenterchipoffthroughtwopaths:

Idleloop
Suspend/Resume

PatrickBellasibellasi@elet.polimi.it

LinuxPM
deviceruntimesuspend/resumesupport

42

Devicedriversresponsibilities
aggressivelymanagerequest/releaseofclocks

throughclockframework=>controltheirclocksonarequestbasis
nottransactionbased=>useinactivitytimertocutoffclocksaftera
periodofinactivity

needtoregisterwiththeLDM

implementsuspend()andresume()calls

specifyconstraintswhenrequiredforitsfunctionalities

e.g.min.frequency,maxlatency,...

needtoimplementcontextsave/restore

beawareofpowerOFFmode

configureoptimalpowersettings

accordingtostandingsystemconstraints

PatrickBellasibellasi@elet.polimi.it

LinuxPM
Examplesofchangesbeingmade

43

Transactionbaseddriverswillcontrolclocksbasedonactivity

e.g.i2cdriverenablesclockswhentherearependingrequestsand
disablesthemwhentherearenopendingrequests
CameraClockswillbeenabledaslongasthedriverisrequired
DisplayThefbdevinactivitytimer(whichistiedtouseractivity)canbeused
toturnoffdisplayclock
MMCClocksarecontrolledonapercommandbasis
GPTimerClocksarecontrolledasperrequirement

i.e.whenatimerisinuse,theywillbeenabledandwillbedisabledwhen
theyarenotinuse
UARTConsoleclocksarecutintheidleloop(beforeputtingcoredomainto
retention)andotherUARTclockscouldbecontrolledonaneedbasis
USBClockscanbecontrolledasperrequirement(onlywhentransfersare
goingon)

PatrickBellasibellasi@elet.polimi.it

LinuxPM
Contextsaveandrestore

Whenalldriversinapowerdomainreleasetheirclocks,
thepowerdomaincangotoRETorOFFstate
thesharedresourceframeworkprogramsthepowerdomaintotarget
statedependingonthelatencyconstraintsinthesystem

44

Driverscanfollowanyofthefollowingmethodstosaveand
restoretheircontext
Alwayssave/alwaysrestore

driverswhichdonothavelotsofregisterscanalwayssavecontextand
restorecontextbecauseitwillnotcausealotofoverhead

Earlysave/restoreondemand

driverssavecontexteverytimetheyreleasetheirclocksbutrestoreit
onlyifthepowerdomainhasactuallygonetooffaftersaving
thismakessensefordriverswhichhavealargerestoretimewithsave
timebeingminimal

PatrickBellasibellasi@elet.polimi.it

What'smissing?

45

InNomadik?....quiteeverything:/

PatrickBellasibellasi@elet.polimi.it

References

46

1. V.Pallipadi,S.Li,A.Belay,cpuidleDonothing,efficiently...ProceedingsoftheLinux
Symposium,Vol.2,June2007.Ottawa,OntarioCanada.
2. WalfsonMicroelectronics,LinuxVoltageandCurrentRegulatorFramework
3. AnAPIforspecifyinglatencyconstraints,LWNArticle,August2006.
4. M.Gross,PowerManagementQoS:HowYouCouldUseitinYourEmbeddedApplication,Intel,
OpenSourceTechnologyCenter.
5. J.Stults,N.Aravamuda,D.Hart,
WeAreNotGettingAnyYounger:ANewApproachtoTimeandTimers,Proceedingsofthe
LinuxSymposium,Vol.1,July2005.Ottawa,OntarioCanada.
6. T.Gleixner,D.Niehaus,HrtimersandBeyond:TransformingtheLinuxTimeSubsystems,
ProceedingsoftheLinuxSymposium,Vol.1,July2006.Ottawa,OntarioCanada.
7. Clockeventsanddyntick,LWNArticle,February2007.
8. Deferrabletimers,LWNArticle,March2007.
9. V.Pallipandi,A.Starikovskiy,TheOndemandGovernor,ProceedingsoftheLinuxSymposium,
Vol.2,July2006.Ottawa,OntarioCanada.
10. R.Woodruff,LinuxsystempowermanagementonOMAP3430,EmbeddedLinuxConference,
April2008.SiliconValley,US.
11. PowerTOP,