Post on 12-Jan-2015
description
transcript
1 Copyright © 2007 Nokia. All rights reserved.
This material, including documentation and any related computer programs, is protected by copyright controlled by Nokia. All rights are reserved.
Nokia Internet Tablet
Power Management
Klaus K Pedersen
Igor Stoppa
2 Copyright © 2007 Nokia. All rights reserved.
Overview
•Current Solutions:•Sleep while Idle•Dynamic Tick
•Future:•Dynamic Voltage and Frequency Scaling•CPUFreq•Dynamic Power Switching
3 Copyright © 2007 Nokia. All rights reserved.
Sleep While Idle
• In the idle loop, always try to go to the target sleep state
•the target sleep state is set based on latency• OMAP1 : ARM idle / Big Sleep / Deep Sleep
• OMAP2 : ARM idle / MPU retention / SoC retention● the lowest sleep state is characterized by clock stop
(including system osc) and lowered VCORE (retention voltage)
The major causes of latency are:● restarting the system oscillator● restoring VCORE to the active value
4 Copyright © 2007 Nokia. All rights reserved.
Dynamic Tick
•Skips system ticks that are not associated with any scheduled activity
•Uses the low freq (32khz) clock from the system XTL to keep track of the time passing
•“Sleep While Idle” can keep the system stopped for longer time
•Now that the 2.6.21 kernel supports tick-less activity, we should switch to the standard implementation
•The current OMAP-specific implementation has drawbacks as it introduces delays when calculating the time for the next wakeup
5 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
Premise:
P=⋅Ceff⋅V2⋅f
:switching factor
Ceff :effectivecapacitance
f :operatingfrequency
V :operatingvoltage
∀Vn∃f MAXn∣f MAXn=MAX [f V n]
E=P⋅TE∝n⋅V 2
P :DynamicPower
E :Dynamic Energy
T :Period of time
n:cyclesdoneduringT
6 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
•The power used by a system depends: quadratically on the voltage applied, linearly on the “work” (freq).
● For any given voltage, there is a maximum frequency at which the system is still stable.
The highest stable frequency available for the currently set voltage yields the maximum efficiency.
7 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
Considerations: Voltage Scaling (CPU only)
T
V Deadline
T2
V2
f 2=MAX [f V 2] E2∝V 22
T
V Deadline
DT1
V1
f 1=MAX [f V 1] E1∝V 12
V 2=V1
2
f 2f 1
WW
E2∝E1
4
Same workload W
Deadline is still met
75% Energy saved
8 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
Apparently the best choice is the minimum voltage V suitable for a frequency f that
can meet the deadline.
But ...
9 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
Considerations: System-wise performance
Also other leakages than the processor must be considered.
Example:
SDRAM (Mobile DDR) current:
•active current ≈ 10 - 30 mA
•self-refresh current < 1mA
OMAP2 current:
•active current > 100 mA
•idle < 2mA
P=PstaticPdynamic
10 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
Considerations: Causes of Latency
There are several causes that can make a transition slow:
•re-lock DPLLs and DLLs ≈ 0.1 ms•re-adjust voltage regulators ≈ 5 ms (present)
target value should be ≈ 0.1 ms
•pause / resume device drivers ≈ 20 - 50 ms
Improving drivers is the way to reduce latency
11 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
OMAP2 DVFS SchemeCurrent Implementation
Cpufreq
OMAP2 DVFS driverboard cfg
OPSettings
Selection List of Frequencies
Voltage Scaling
Set Vtg
Drv 1 Drv 2 Drv n...
Clk FW
Update
12 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
OMAP2 DVFS Interfaces
Toward OP selector (Cpufreq):
•Get frequencies & OP list
•Set target OP
•Get latency
Toward drivers:
•Register / unregister
•Send sync / async pre and post notification
13 Copyright © 2007 Nokia. All rights reserved.
Dynamic Voltage & Frequency Scaling
OMAP2 DVFS
Sequence:● Request of new OP● Pre-notification to drivers● Wait for ACK from all drivers● Change Voltage (if needed)● Adjust clocks● Tell Clk FW to sync up with● Post-notification to drivers
14 Copyright © 2007 Nokia. All rights reserved.
CPUFREQ: Lessons learned
•Expressing Constraints
•Determinism
•non-polling governor
•ondemand transition_latency misuse
15 Copyright © 2007 Nokia. All rights reserved.
Expressing Constraints
A real life case: OMAP2 speed sorted (N800):
● Constraints should be described by referring to the frequency that they are addressing
Ex: DSP requires dsp_fclk >= 220MHz rather thanDSP requires OP1
OP ARM [MHz] DSP [MHz]0 400 1331 330 2202 266 1773 165 85
16 Copyright © 2007 Nokia. All rights reserved.
Expressing Constraints: Ranges
● Functional constraints are mapped into sets of valid states to enable much richer operations.
Example: ● For embedded targets there would be a one-to-one
mapping between operating-point and bits in the vector.
● For PC's ACPI: P states are really OPs
OP0OP1OP2OP3OP4OPn ...
17 Copyright © 2007 Nokia. All rights reserved.
Towards deterministic behaviour
•cpufreq_set_policy(): still broken
•If there are non overlapping policies, a random frequency will be selected
•No way to validate a policy is respected.
•RFC: the callback could be replaced with a registered / unregister (frequency) policy interface.
static struct cpufreq_constraint mypol = { .prio = OR_DIE; .low = FREQ(OP1); ...err = cpufreq_register_constraint(&mypol);...cpufreq_unregister_constraint(&mypol);
18 Copyright © 2007 Nokia. All rights reserved.
CPUFREQ non-polling governors
• The ondemand sawtooth frequency switching algorithm has many good properties.
• It should be possible to create a non-polling governor with the properties of ondemand. All what is required is call-backs/notifications from idle.
f
idlet
Given Tidle* Compute new
(lower freq)* Start timer for
going up
timertimer
19 Copyright © 2007 Nokia. All rights reserved.
CPUFREQ: transition_latency misuse
•ondemand uses transition_latency to calculate
the polling interval (1000x).
•this weird relation is artificial.
•Introduce:
•polling_interval
•relax_interval i.e. the minimum time to
stay on a newly selected frequency.
20 Copyright © 2007 Nokia. All rights reserved.
Introduce concept of Target Idle state
•For the coming System on Chip in finer geometries we will have to utilize even lower Idle-states like – off(!)Problem: off state introduces longer latencies
•We need a mechanism to select the target idle-state.
•CPUFREQ could adjust the idle-state that matches the state of the system (mostly idle vs mostly active).
•Potential better performance and bigger power-savings.
21 Copyright © 2007 Nokia. All rights reserved.
Conclusion: Simple rules
•Run as fast as you can for the given the voltage.
•Goto to idle with clock-stop when nothing to do.
•You can't predict the future – so forget about fine-grained frequency control.
•The time spent in idle vs active (a'la OnDemand) is a good key for selecting system performance settings.
•Don't change frequency too often or you waste cpu-time waiting for drivers to pause and restart peripherals.
22 Copyright © 2007 Nokia. All rights reserved.
Conclusion: Improvements
OMAP2 DVFS Interfaces
•Use smp-like approach for ARM-DSP•Get frequencies & OP list for each core•Get latency for each OP transition•Add transaction support to clk FW•Cpufreq to use threaded notifications
23 Copyright © 2007 Nokia. All rights reserved.
Conclusion: Challenges
•Non-SMP systems, with independent OS but intermingled clock and voltage control
•Relative high current usage by support components -> nullifies benefit of low frequency and voltage operation point in a dynamic idle system.