2/11/2004 1

Power Management

2/11/2004 2

Outline:• Introduction to the topic

• Part 1: Vertigo– How can power consumption by a processor be reduced?

– What is DVS?

– Performance setting algorithms

– Policy stack

– Evaluation

– Conclusion

• Part 2: Cooperative I/O– Components of Cooperative I/O

– Low power modes

– Cooperative File operations

– Cooperative Updates & DDT

– Prototype Implementation

– Experiments & Results

– Conclusion

2/11/2004 3

2/11/2004 4

What was some of the common things among these devices you just saw?

2/11/2004 5

Power Management

The goal of power management is to combine high performance with low power

consumption.

2/11/2004 6

How can we better manage power ?

• Develop longer lasting batteries.

• Reduce the power consumed by processor/CPU

• Reduce the power consumed by the network

interface and user interface and during I/O.

• Application driven power management which

involves developing energy aware applications.

2/11/2004 7

Part 1: Vertigo

2/11/2004 8

Reduce the power consumed by the processor

3 possible solutions to the problem

– By taking advantage of the highly variable performance

requirements of the application.

– By Dynamic Voltage Scaling(DVS) involves reducing the clock

frequency and corresponding operating voltage of the CPU.

– By reducing the static power consumption, which results from

leakage current in CMOS devices. Using techniques such as

Adaptive reverse Body Biasing(ABB).

2/11/2004 9

• DVS(Dynamic Voltage Scaling) exploits the fact that the peak frequency of a processor implemented in CMOS is proportional to the supply voltage, while the amount of dynamic energy required for a given workload is proportional to the square of the processor’s supply voltage.

– In simple “running the processor slower means that the voltage level can

be lowered, yielding a quadratic reduction in energy consumption, at the

cost of increased run-time”

– So the key is to reduce the processor’s performance level so as to be able

to exactly meet the software deadlines not to run the processor at its peak

level at all times.

• Similarly, static power consumption due to leakage can be significantly reduced if processor does not operate at its peak performance level.

2/11/2004 10

Dynamic Voltage Scaling

• Simple approach to do voltage scaling is based on the usage model(not on the workload). This approach does not need any OS support.

• Another approach is to build the power management policy into the processor’s firmware. This approach also does not require any modifications to the OS.

• The approach used in Vertigo is to build power management policy as hooks to the already existing OS. This helps it to get access to a richer set of data for making performance perdictions.

2/11/2004 11

Vertigo[1]

Design objectives of the Vertigo system:

• To be minimally intrusive into the host operating system. So as to make it autonomous from the other units of the kernel.

• To automatically set the processor performance, without any application specific involvement.

• To be able to run it in passive mode in order to monitor the system.

2/11/2004 12

Vertigo Architecture

• Vertigo is implemented as a set of kernel patches that hook into the Linux kernel to monitor the program execution and control the speed and voltage levels of the processor.

• Vertigo co-exists with the existing scheduler, system calls and power manager.

• It uses a composition of performance setting algorithms, all specializing in diffirent kinds of run-time situations.

2/11/2004 13

Performance Setting Algorithms

They can be broadly divided into two categories

1. Those that use information about task deadlines in real-

time kernels to guide performance-setting decisions of the

processor.

2. Those that seek to derive deadlines automatically by either

monitoring the past utilization of the processor(interval

based techniques) or based on semantic task and event

classification.

Note: Vertigo’s performance setting algorithms fall into the 2nd category.

2/11/2004 14

Vertigo’s Performance Setting Algorithms

• The multiple performane setting algorithms are co-ordinated to

find the best estimate for the necessary performance level.

• Hence there is a decision hierarchy, were the top level

algorithms have a right to override the lower levels.

• Vertigo has three levels of decision hierarchy1. Top level - This algorithm quantifies the performance

requirements of an interactive application.

2. Middle level- An application specific layer, where DVS aware applications can submit their information.

3. Bottom level- The algorithm tries to estimate future utilization based on past information.

Note: The focus of the paper is on the top level and bottom level algorithms.

2/11/2004 15

How to quantify Work?

The full speed equivalent(fse) work estimate is computed by

Workfse= ni=1 tipi (Eq 1)

where i refers to one of the n different performance levels during a given interval with the corresponding

amount of non-idle time spent at that performance level(ti) in seconds and frequencies(pi) specified in

fraction of peak performance

The equation basically states that the workload’s runtime is linearly related to the inverse of the

processor’s performance level.

2/11/2004 16

Perspective-based Algorithm

• It is the algorithm used at the lowest level of the policy stack.

• It is called perspective-based, since it computes the performance

predictions from the perspective of each task and uses the combined

result to control the performance setting of the processor.

• Vertigo computes each task’s observed period for recomputing per-

task exponentially decaying averages of the work done during the

task’s period and of its estimated deadlines.

• Performance level is got by

Perf= WorkEst/ Deadline (Eq 4)

• To find the task’s period, the algorithm tracks the time from when the

task starts executing, through points when it is preemepted and

eventually runs out of work, until the next time it is rescheduled.

2/11/2004 17

Task PeriodAt point c the Workfse is computed for the period between a and c.

2/11/2004 18

WorkEst and Deadline

WorkEstnew= (k* WorkEstold + Workfse)/ (k+1)(Eq 2)

Deadlinenew= (k*Deadlineold+Workfse+Idle)/(k+1)(Eq 3)

Note: k is a constant whose value is choosen as k=3.

2/11/2004 19

Advantage: By keeping track of work and deadline predictions seperately the performance predictions are weighted over the length of the interval over which the work estimates are measured.

Disadvantage: If a new non-interactive, CPU-bound task that utilizes the CPU without being preempted, there is significant latency incured in responding to the load.

This is overcome by placing a limit over the non-preempted duration over which the work estimate is computed.

They have choosen a value of 100ms after which is a task is not preempted the work estimate is recomputed.

2/11/2004 20

Top level Algorithm(1)

• The middle level- DVS-Aware Applications can submit their requirements to this layer. But it has not been currently implemented in Vertigo.

• The top level- The algorithm automatically quantifies the performance requirements of interactive applications and ensures that software deadlines are met, so that user experience does not suffer.

• An interactive episode is started by the user through a GUI event.

• This event gets handled by the GUI controller and the appropriate task handler.

• Therefore by monitoring the appropriate system calls, Vertigo can detect interactive episodes .

• The GUI controller, the task handler and all other tasks initiated by these are marked as interactive tasks.

• An interactive episode ends when there are no more interactive tasks to perform.

2/11/2004 21

Top level Algorithm(2)

• Skip threshold: It is set to a value of 5ms.

• Panic threshold: If the interactive episode

does not end by this point the processor

performance is increased to the

maximum. It is set to 50ms.

• Perception threshold: If an episode is

longer than both the skip and the

perception threshold then the

performance requirement is set to 100%

• Perception threshold describes a cut-off

point under which events appear to

happen instantaneously for the user.

• The perception threshold depends upon

the task and user but 50ms is commonly

used.

2/11/2004 22

Top level Algorithm(2)

• The predictions for the interactive episodes are as exponentially

decaying averages of the correct settings of the past interactive

episodes.

• If the panic threshold was reached during an episode, the moving

threshold is rescaled so that the last performance gets incoporated

with a higher weight. (k=1 instead of k=3)

• The performance requirements of the interactive episodes shorter than

the perception threshold is calculated as

Perf= Workfse/ Perception Threshold (Eq 5)

2/11/2004 23

Policy Stack and Work Tracking in Vertigo

• The policy stack keeps track of the various commands and performance level requests from each policy and uses this information to combine them into a singel global performance level decision when needed.

• The policies can be triggered by any event in the system and they may submit new performance requests at any time.

• The algorithms use processor utilization history to compute performance level, hence they need to be able to track the work done over an interval.

• This is done is by the policies in Vertigo by making use of structure called “Vertigo_work”.

• This not only simplifies the policy code but also simplifies the porting of Vertigo.

2/11/2004 24

Evaluation• Sony Vaio PCG-CIVN notebook computer

• Transmeta Crusoe 5600 processor running at 300MHz to 600MHz with 100MHz steps.

• This particular model was used because it had its own power management done at the firmware level which could be turned on or off. Thus it was useful in evaluating Vertigo.

• LongRun is the power management system of Crusoe.

• The OS used Mandrake 7.2 with modified Linux 2.4.4-ac18 kernel

2/11/2004 25

Table 3: Application level statics about the plaympeg benchmark

2/11/2004 26

2/11/2004 27

Figure 8: Fraction of the time spent in different interactive workloads

2/11/2004 28

Conclusion• Plus

– The idea for using more than one performance setting algorithm in a policy stack

– The Linux kernel itself wasn’t modified.

– The applications need not be energy-aware

– The system showed good results in most situations

• Minus– It would have been interesting to see the actual energy savings.

– The amount of energy saved by optimising the energy consumption of the processor alone may not be significant

– The applications need to be energy-aware to make use of the middle level of the performance stack.

• The ideas used in Vertigo can be used along with other power management methods for overall improvement.

2/11/2004 29

Part 2 Cooperative I/O- A Novel I/O Semantics for Energy Aware

Applications

2/11/2004 30

Cooperative I/O- A Novel I/O Semantics for Energy Aware Applications[2]

• Integrates the application layer into the dynamic power management of devices.

• Energy-aware applications make use of the new interface operating system to do cooperative I/O.

• The basic idea is for the OS to batch deferable requests in order to create long idle periods during which switching to low-power mode pays off. Ex: Auto-save function of the text editor.

• The proposed model consists of three major parts– New co-operative file operations that have time-out and cancel flags as

additional parameters.

– The update policy of the OS is re-designed to save energy.

– The OS controls the hard disk modes by using a simple algorithm called “Device-dependent time-out” or DDT.

2/11/2004 31

Components of Coop-I/O

2/11/2004 32

Low power modes(1)

• The OS may reduce the power consumption of a device by switching

between the device’s operation modes.

• The ATA standard, defines 4 operation modes for the hard disk

– Active mode: The hard disk is reading,writing,seeking or spinning

– Idle mode: The disk is rotating and the interface is active but the head is

in the parking position.

– Standby mode: The disk spindle motor is off, but the interface is still alive

– Sleep mode: Both the spindle motor and the interface are off. To

reactivate we need the reset command.

• The device is “shut down” if it is in the Standby or the Sleep mode.

2/11/2004 33

Low power modes(2)

• A non-negligible amount of time and power is required to enter and

leave these modes.

• Break-even time is defined as the minimum interval between 2 disk

operations for which the switching will pay-off.

• The break-even time is dependent on the characteristics of the disk.

• Stand-by time: If the interval of idleness is longer than the break-even

time then it is called the stand-by period.

2/11/2004 34

Cooperative File Operations(1)• These operations provide a way for applications to exert influence on

the way the hard-disk operates.

• Three cooperative variants to the commonly used file operations:– open_coop()

– read_coop()

– write_coop()

• In addition to the standard parameters these operations have 2 additional parameters, the time-out and the cancel flag.

• The time out value specifies when the operation is initiated at the latest and the cancel flag specifies if or not the particular operation can be aborted.

• In case of legacy applications their open(), read() and write() map on to the corresponding cooperative variants but with time-out and cancel flag set to zero and inactive respectively.

2/11/2004 35

Cooperative Read operation

• Copies of the disk blocks are kept in a cache in main memory, called the block buffers, to reduce the number of slow disk opertions.

• Modified block buffers are marked dirty and the “dirty buffer life span” determines the time when these buffers must be written back to the disk.

• Cooperative read: – Checks to see if the block is in the cache, if yes, retrieves it.

– If not, checks if the disk is in the active or Idle mode, if yes, then the block is retrieved immediately.

– Else, it waits until the disk spins again or the time-out has elapsed.

– If the time-out has elapsed then it checks the cancel flag to determine whether to restart the disk or abort the read operation.

2/11/2004 36

Cooperative Write operation

• If the block is cached, the update task defers write operation until the

dirty buffer life span has elapsed.

• If the block isn’t cached, then the write may induce a read operation,

so that the block can be read into the main memory before it can be

modified.

• The situation gets more complicated when the write operation needs to

read an uncached block after several modifications to the cached

block.

• The problem overcome using the early commit/abort strategy

2/11/2004 37

Early Commit/Abort Strategy(1)• Decides to commit or abort as soon as the first modification to a block

buffer is going to take place.

• Assume, we want to modify the buffer and the drive is in standby mode,

then we can distinguish 3 situations:

– The drive is activated by another request before the time-out for our request is

reached.

– If at the end of our time-out there are no other dirty buffers to the drive,

depending on the cancel flag we can either commit or abort the write operation.

– If there is another dirty buffer for the drive. In which case we wait until old

requests time-out elapses and the drive is started.

• A write to a block is delayed only as long as the drive is in standby mode

and there are no dirty buffers for that drive.

2/11/2004 38

Early Commit/Abort Strategy(2)Therefore since a write operations first buffer modification involves

committing the operation, a write can be committed even if the disk is

not running.

Also an abortable write will not be aborted after the time-out even if the

disk is in standby mode. This is case when a read follows a commited

write– The disk is in standby and there exists dirty buffers for the disk

– The write operations has to modify several disk blocks.

– The write operation is commited after the first modification.

– If a subsequent block is not cached, it has to be read from the disk.

– This action will be deferred until time-out has elapsed.

– We have to spin the disk then to read the block as the complete operation is already committed.

2/11/2004 39

Cooperative Open Operation• An open operation can cause a read or a write operation if the file

has to be created or truncated.

• For the open_coop(), the read and write induced by it are mapped to their corresponding cooperative counterparts.

Usage of the cooperative operations:

• Since the coop operations can be delayed the I/O must be handled by a separate thread in the program so that data is cached by it for the main thread.

• The main thread thus reads and writes data to the buffer as if there is no cooperative I/O.

2/11/2004 40

Cooperative Updates• Cooperative Update tries to optimize the caching mechanism with

respect to power consumption.

• The update process usually takes place when one of the following conditions are met– An explicit sync() command forces a write back of the buffers to disk

– The dirty buffer life span has elapsed

– A certain percentage of block buffers are dirty

– System needs main memory and has to do a write back to reclaim memory

• The problem with the above policy is 2 updates can be spaced with a time period that is shorter than the break-even time.

• Solution: Try to batch write requests so that device can spend more time in low power modes.

• The policy is called “Drive specific cooperative updates”

2/11/2004 41

Drive specific cooperative updatesIt consists of 4 strategies:

• Write back all buffers instead of only the oldest ones

• Update cooperatively: The OS tries to combine other disk access such as

read requests and writing back dirty buffers whose “dirty buffer life span”

hasn’t yet elapsed.

• Update each drive seperately: It may help to increase the update interval

for a singel drive, also balance the I/O load, yet the same time it will not

compromise on file system consistency.

– But this would require us to maintain the oldest dirty buffer for each individual

drive along with a list of all the dirty buffers that belong to that drive.

• Update on shutdown: If the drive is planning to shutdown write back all

the dirty buffers belonging to that drive.

2/11/2004 42

Device dependent time-out(DDT) policyThe policy states:

Shut down the hard disk if

tla + tbe =< twhere

t : The current time

tla : The time of the last hard disk access

tbe : The break even time

Thus the disk drive has to keep track of tla and tbe

2/11/2004 43

Prototype implementation• They have implemented the Coop-I/O concept in the Linux kernel

version 2.4.10.

• They have also made the following modifications– Cooperative file operations: In additions to the already mentioned file

operations a function, wait_for_drive() is provided to block them when the drive is not active.

– The VFS and Ext2 file system have been modified to support the drive-specific cooperative update policy: By mapping device numbers to drives, also now the need for cooperative updates is checked every time a one reads or writes to a drive.

– The IDE driver has been enhanced by power mode control for disk drivers, which includes the DDT algorithm. DDT algorithm is implemented as a timer based function that is called every 1sec.

2/11/2004 44

Experiments and Results

• Experiments were run on a– personal computer running Linux kernel

– with a IBM Travelstar 15GN hard disk.

– Power measurements where taken using 4 analog-to-digital convertors

• Testing a cooperative Audio player– the application was modified to make it energy aware

• Two audio files were played, with the same length but different compression ratios. – The two audio files were used, both alone and also companied by a mail

reader.

• All the tests were run for 534 seconds.

2/11/2004 45

The system was tested under 4 strategies:

• Cooperative: Use DDT and new buffer cache and update mechanism.

Read_coop() has a delay time equivalent to the play time for one semi-

buffer.

• ECU(Energy aware Caching and Update) : Same as above but instead

of read_coop() function a standard read() was used.

• DDT only: Use DDT with the original buffer cache and update

mechanism

• None: Do not use any power saving mechanism at all

• Uncooperative Oracle policy : Values for this are derived from

running the unmodified Linux. This represents the theoritical lower

bound.

2/11/2004 46

Figure 4 & Table 1- compares the 4 strategies

2/11/2004 47

Figure 5- compares the 4 energy saving strategies(playing “Toccata” without mail)

2/11/2004 48

Figure 6- compares interaction between 2 independent tasks, “Toccata” and Mail cooperative.

2/11/2004 49

Reads and Writes with varying average period length• Multiple tasks periodically read or write data• The energy consumption was measured over 1000seconds• The read and write processes have varying period lengths and idle times

2/11/2004 50

Fig 9: Varying the number of cooperative processes

The energy consumption steadily declines with the increasing proportion of cooperative processes.

2/11/2004 51

Better way to show the results

2/11/2004 52

Conclusion• Plus

– Addition of even a single cooperative application shows reduction in the energy consumed by the disk.

• Minus– The Coop-I/O’s experimental results wasn’t compared against any of the

benchmarks or other already existing low power I/O systems.

– The paper makes a claim of 50% power reduction which is not sufficiently supported or shown through experiments.

– Requires modification to the user applications, requiring the applications to be energy aware.

– There are no comparisions between the various strategies with respect to the amount of time the disk is active, idle and in standby.

– Also the idea of coop-I/O has not been tested on any of the other commercial avialable hard disks.

2/11/2004 53

Something to think about

Is power management a good idea?

2/11/2004 54

Reference:[1]. Vertigo: Automatic Performance Setting for Linux, Krisztian

Flautner, Trevor Mudge. Proceeding of the 5th symposium on operating system design and implementation, 2002.

[2]. Cooperative I/O- A Novel I/O semantics for energy aware application, Andreas Weissel, Bjorn Beutel, Frank Bellosa. Proceeding of the 5th symposium on operating system design and implementation, 2002.

[3]. K.Flautner, S.Reinhardt, t.Mudge. Automatic performance setting for dynamic voltage scaling. Proceedings of the International Conference on Mobile Computing and Networking, July 2001.

[4]. K.Flautner, S.Reinhardt, t.Mudge and R.Uhlig. Thread level parallelism and interactive performance if desktop applications. Proceeding of Conference on architectural support for programming languages and operating systems. November 2000.