Power-Aware Operating Systems using ACPICS 736 Project – Fall 2001

Saisanthosh Balakrishnan and Jyothir Ramanan{sai, jyothir}@cs.wisc.edu

Abstract

The idea behind today’s power management is to reduce the power usage of systems when someone walks away fromtheir PC or stops using after a period of time, by sending the hardware into a “sleep mode” or “power-saving mode”.Hardware components such as processors, memory chips and disks have advanced power management techniques (besides“power-saving” modes) to consume less power. However, operating systems are being designed with little regard forpower consumption. Even though, operating systems control hardware resources, and provide a virtualized interface forapplications running on top it, they are largely unaware of power-saving optimizations that hardware has (does). With theprolific growth in the usage of laptops, PDAs, servers and workstations, operating systems and applications need to be awareof how much power they consume. In this project, we propose a model that uses the ACPI specifications to make operatingsystems and applications power-aware. The model uses an user-level power manager to make most of policy decisions forconserving power without significantly compromising performance. We use this model to implement hard-disk spin-downand temperature sensitive scheduler.

1 Introduction

Mobile PCs, desktop machines, servers, palmtops all needto have some sort of power management. However, themeaning is dependent on the system. Mobile PCs needto have aggressive power management functionality. Im-portant aspects that affect mobile systems are battery life-time and heat dissipation. Power-managed desktops arethe ordinary home and “green” PCs. Servers can get largepower savings by operating in two modes: day and night.In day mode, servers are in working state all the time,but putting unused devices into low power states when-ever possible. Servers have high-performance peripheralsthat consume lot of power, and switching them to sleepmode, helps obtain significant power savings. In nightmode, the power managers on servers could be more ag-gressive, switching all devices to sleep mode.

Hardware devices present in these systems, have advancedpower-switching and power-saving modes. However, themanagement layers on top of these devices are badly de-signed and overly conservative. Strategies to transition be-tween states requires knowledge about the characteristicsof each mode. That is, the layers above the hardware needto know the advantages and disadvantages of each mode,how much power is saved by being in it, and how muchfunctionality is sacrificed by entering it.

We discuss briefly the power management schemespresent in hardware, APM and software in Section 2. Sec-tion 3 talks about ACPI, and Section 4 on how our modelexploits ACPI. Our methodology, two implementations:hard-disk spin down and temperature sensitive schedulerin Sections 5, 6, 7. We conclude with related work in Sec-tion 8 and conclusion in Section 9.

2 Power Management

At the processor level there has been ever increasinggrowth in complexity, clock frequency and die size. Thisis driven by advances in semiconductor technology andthe quest to keep up with Moore’s law from a perfor-mance viewpoint. Power consumption of complex pro-cessors such as those implementing simultaneous multi-threading, on-chip multiprocessing cores increases dras-tically. Architects have been proposing and implement-ing various techniques to considerably save power. Forexample, Transmeta Crusoe’s [13] Long-Run technologydoes frequency and voltage scaling to reduce power con-sumption. Processors also turnoff functional units whennot used. More advanced techniques include: fetch andcommit bandwidth throttling, slotted instruction windowswherein, a slot can be powered down if it is not used etc.

DRAM chips are power-aware and provide differentpower modes. For example, Rambus RDRAM delivershigh bandwidth, with narrow bus topology operating ata high clock rate. It provides four power modes: active,standby, nap and powerdown in order of decreasing powerconsumption and increasing access time. RDRAM needsto be in active mode while performing read or write opera-tions, thus consuming maximum power. The other modeshave additional clock resynchronization delays associatedwith it. The appropriate mode has to be picked by predict-ing the future requests.

Hard disks have five power modes; in order of decreasingpower consumption, these are active, idle, standby, sleepand off. In active mode, the disk is seeking, reading orwriting. In idle mode, the disk is not seeking, reading orwriting, but the motor is still spinning in the platter. Instandby mode, the motor is not spinning and heads are

1

parked, but the controller is still on. In sleep mode, ev-erything is shut off. Transitions are generally controlledby the HDD controller. Turning off or on the hard diskmotor consumes considerable power. Thus, the strategiesfor switching modes should be more conservative thanDRAM or processor. In all the above cases, the hard-ware resources have various power-saving modes. Thecontrollers switch between modes based on request fromhigher levels such as the BIOS or operating systems.

The power interface provided by the hardware, can be usedby BIOS or applications. The de-facto power manager inthe BIOS is APM or Advanced Power Manager. APM canshutoff devices when they are idle for the time specifiedby the user or the system. APM is known to be buggy,unreliable and sometimes overly conservative. Applica-tions could also use the interface provided by the hard-ware. Classic examples include: adaptive and predictivestrategies that spinoff disks, switching network interfacecards to sleep mode etc. Most of these applications usethe past history of usage and predict future accesses toturnoff devices. The problem with both APM and appli-cations managing power is that they become highly deviceand implementation specific. For example, each hardwaredevice has its own power-interface, hence the applicationswritten on top those devices, can run only on that particu-lar power-interface.

3 ACPI

The Advanced Configuration and Power Interface (ACPI)specification was introduced by Intel, Toshiba andPhoenix (joined later by Compaq and Microsoft). It de-fines the hardware and software interfaces that enable op-erating system directed power management system to con-trol the power of various motherboard components. Itwas developed to establish common interfaces for vari-ous hardware devices enabling operating systems to di-rect power management of both devices and entire sys-tem. ACPI evolves from the existing collection of powermanagement BIOS code, Advanced Power Management(APM) application programming interfaces, tables and soon into well-defined power management and configurationinterface specification. ACPI provides the means for anorderly transition from existing legacy hardware to ACPIhardware, and it allows for both ACPI and legacy mech-anisms to exist in a single machine and to be used asneeded.

3.1 ACPI Specification and Structure

ACPI defines the hardware and software interface and thedata structures that exist at this level. The specificationdescribes the interfaces between components, the contentsof the ACPI System Description Tables, and the related se-

mantics of the other ACPI components. The ACPI SystemDescription Tables, is the heart of the ACPI implemen-tation and the role of ACPI system firmware is primarilyto supply the ACPI tables to the layers above it. ACPIis merely a software-hardware specification. More detailsabout ACPI specifications and the table it exposes can befound in ACPI specifications [6].

3.2 Goals

The primary goals of ACPI are:

1. The interfaces should be applicable and suitable toall classes of computers including desktops, mobileworkstations and server machines.

2. ACPI compliant hardware devices should providean uniform interface. They implement 4 processorstates, 4 different global states and 5 different sleepstates (S0 – S5). For example, S5 is soft off state,S4 is sleeping state. S4 consumes more power thanS5, but takes less time to wakeup from sleep mode.

3. Machine implementers have the freedom to imple-ment a wide range of solutions, while still maintain-ing full OS support.

4. Implementation of power management at operatingsystem level will make it practical for the OS andapplication to be aware of power consumption.

In traditional systems, the hardware-software interfacealso known as BIOS uses the power interface provided bythe hardware to switch modes. The de-facto standards hasbeen the Advanced Power Management system or APMintroduced by Intel and Microsoft. The user specifies time-out values for various devices such as disks and networkinterfaces. The BIOS switches to power saving modeswhen the device is inactive until it hits the timeout. Forexample, a hard disk is made to spin down to save power,the network interfaces are switched to sleep state, memoryis moved to power down state, processors are switched tolower frequency and/or voltage etc.

With this traditional style of power management, BIOSdoes a significant amount of work. The policies imple-mented in the ROM BIOS are rather too simple, as it iscomplicated to write BIOS code. Besides that, the poli-cies are fixed, as the code that implements various policiesare burned into ROM.

ACPI is a substitute for APM at the hardware-softwarelevel. However, ACPI unlike APM does not deal withpower management. Instead it exposes the tables presentin various hardware devices present in the system to theoperating systems. ACPI lays the responsibility of power

2

management on the operating system as it is in the bestposition to make judgments relating to power manage-ment. In effect, the ACPI is merely standard, encourag-ing: hardware vendors to provide standardized interfacethat is ACPI compliant, encourage operating systems toexport the tables that ACPI exposes, to the applications.Now, much of the work is done at the OS level and not thehardware or BIOS level.

Implementing ACPI at the OS level is much easier. Var-ious policies can be implemented for devices present inthe system. It encourages hardware vendors to just pro-vide the interface for switching power states, and not actu-ally do any power savings. This means that, we now havean unification of power management algorithms in the OSwhich will reduce conflicts between hardware, firmwareand will enhance reliability. Power management at the OSlevel also allows us to implement complicated policies, al-lowing the users to turn the knob between conservativeand aggressive power saving modes. Advantages of ACPIinclude:

1. Moving power management functionality into theOS makes it available on every machine on whichthe OS is installed. The level of functionality (powersavings, and so on) varies from machine to machine,but users and applications will see the same powerinterface and semantics on all ACPI compliant ma-chines.

2. Power management is not restricted at the BIOSand the hardware level. With ACPI and a suitablemodel, applications can tune themselves and con-serve power.

3. There is much less state information for the BIOS toretain and manage because the OS manages it. Thisleads to a simpler implementation at the BIOS level.

4. Power management algorithms are unified in theOS, yielding much better integration between theOS and the hardware.

5. OS can deal with power management of devices dy-namically, as the interface provides dynamic regis-tering or loading and unloading of devices.

4 Model

We designed and implemented a software architectureover ACPI, that allows system designers to perform powermanagement at user level. The model is shown in Fig-ure 1. The filter driver implemented as a kernel moduleis attached to the device driver for that particular hard-ware. The filter driver is capable of filtering out necessary

events, and sending it to power manager. The events sentto the power manager will then be used to make some de-cisions based on policies. For example, a disk filter driverwould filter out the id of the process writing to the disk,the block number, number of bytes read or written etc.

Filter Driver

Device Driver

Operating System

Power Manager

Applications

HardwareDevices

Figure 1: Model

The power manager is an user-level application that getsfeedback from the filter driver in the kernel, and from theapplications. The power manager is capable of monitoringthe activities to and from a particular device, and also cansend request packets for power management. It takes pol-icy decisions based on the information about the systemparameters and the requests. System parameters includethe power at each state, transition energy and delay. Thepower manager issues state-transition commands to a sys-tem or a device to meet the performance or power require-ments. As it resides outside the operating system, design-ers can evaluate new policies and algorithms on real ma-chines without knowing the details of the ACPI. The de-signers also need not deal with the interaction of the hard-ware and device driver, except for writing a filter driver.

Also, application programs can request task-specificpower management on multiple devices by communicat-ing with the power manager. For example, a programthat requires the network adapter, and the hard disk couldcommunicate this to the power manager, well in advance.The power manager receives and validates the request, andwakes up the network interface and hard disk before theaccess starts, to hide the latency of wake up. Similarly, anapplication could indicate to the power manager when it isdone with accessing and reading from the disk. The powermanager could spin off the disk immediately to conservepower. The applications communicating with the powermanager allows very aggressive, yet effective power con-servation. However, operating systems are not single-usersingle-program based systems. Many users can run morethan one job at the same time. The power manager willhave to receive requests from all applications and arbitratecommands to the hardware accordingly.

3

5 Methodology

Our model was implemented on Linux Kernel 2.4.14, run-ning on a Intel PIII (700 MHz) with ACPI compliant hard-ware. The kernel was first patched to support ACPI.

5.1 Traces

Trace Hours Applications Usedtrace1 8.37 X, netscapetrace2 1.46 gcc, as, ldtrace3 1.56 X, kdetrace4 1.91 X, gnometrace5 5.77 X, netscape, xmms, vimtrace6 3.44 kernel compile & development

Table 1: Traces – Time and Applications

For hard-disk spin down we implement and report resultsfor different policies. Hence, we need repeatable disk ac-cesses for fair comparison [21, 23] For this, we imple-mented the tracer module as a part of the filter driver forthe disks. The filter driver was used for spinning downdisks and will be explained in the next section. We gath-ered six different traces. All traces were collected on aToshiba Laptop 700 MHz, 128 MB RAM, running LinuxKernel 2.4.14. The filter driver was implemented over IDEand SCSI disks and was capable of filtering out events andsending it to power manager.

The filter driver for the disks was completely transparentto the users and adds no noticeable processor load to thesystem. We logged the trace data to a dedicated partitionin the disk to avoid perturbing the system being measuredwith our tracer traffic. Each trace recorded,

1. Process Name and ID of the process writing or read-ing from/to the disk.

2. Type of operation (Read or write).

3. Major number and Minor number of the device.

4. Length of blocks, and the block number.

5. Time (jiffies) during which the read or write activityhappened.

The traces collected disk activity when compiling kernel,playing mp3s, using X Windows, reading documents, edit-ing and developing C programs. Table 1 describes the 6traces collected.

5.2 Hard Disk

We used Seagate Barracuda ST330630A hard disk in ourexperiments. The hard disk supports two states in which

the disk is spinning (idle and active). The hard disk tran-sitions from read/write (i.e. active) to idle states, whenthere are no read and write requests. The hard disk alsosupports two power down states – the standby and sleepstates. The power manager can control the transitions be-tween the idle and sleep states. Once in the sleep state,the hard disk waits for the first service request arrival be-fore returning or spinning up back to idle or active state.The transition latencies and power consumed in each ofthe states are shown in Table 2.

Spindle Speed 7200 RPMPowerRead and Write Power 9.7 wattsSeek Power 12.5 wattsIdle Power 8 wattsStandby Power 1.5 wattsSleep Mode 0.8 wattsLatencyStandby to Ready 10 secondsSleep to Ready 11 secondsAverage Latency 4.2 msecondsAverage Seek Time 8.2 msecondsTrack-to-Track Seek Time 1.2 mseconds

Table 2: Hard Disk Parameters

6 Hard Disk Spindown

Disks in mobile computers such as laptops consume 24to 54 % of total system power, or more. The power con-sumed by the disks can be reduced by spinning down thedisk, when not in use. A spin-down policy, however, hasto meet two conflicting goals: reducing energy consump-tion and preserving interactive response. Spinning downthe disk after a short period of inactivity can decrease en-ergy consumption, but will also result in more delays dueto spin-up.

Disk spin-down algorithm continually decides whether ornot to spindown the disk drive based on the patterns ofprevious usage or timeout values. Alternatively, we canview the disk spin-down algorithm as suggesting, aftereach disk access, a delay or timeout indicating how longan idle disk is kept powered before spinning it down. Wecan then treat the problem as a sequence of trials, whereeach trial represents the idle time between two consecutiveaccesses to the disk. The disk is spun down if and only if itremains idle for at least the number of seconds equal to thetimeout. The two views of disk spin-down are equivalentwhen the algorithm is allowed to choose different timeoutsfor each trial.

Most systems, use a fixed threshold policy, where a time-out value T is set. If the disk has not been accessed forT seconds it is spun down. Usually, the threshold T is of

4

the order of many seconds or minutes to delay from on-demand disk spin ups. Another reason for setting largethreshold values is to minimize the number of shutdownsand spin-ups, as these increase the energy consumptionsignificantly. After being spun down, the disk must stayspun down for a period of time in order to amortize thespin-up overhead. The break-even point Td, depends onthe time and energy consumed in each state and can bestatically calculated based on the parameters for a disk [9].A fixed threshold shorter than Td can in some cases in-crease energy consumption, and the closer the thresholdgets to spinning down the disk immediately, the greater thelikelihood of increasing rather than decreasing the energyconsumption. Hence, greater the disk inter-arrival times,the more effective an aggressive spin-down policy can be.

Adaptive spin-down policies monitors and adjusts thespin-down threshold to keep a balance between energyconsumption and undesirable spin-ups or bumps that ex-ist. Our project shows the usefulness of ACPI in makingoperating system power-aware. We do not propose anynew disk spin-down strategies. Note that any adaptive orpredictive disk spin-down strategy can be implemented atthe operating system and at software level. The policiesare now much easier to implement with this model, andare not device specific.

6.1 Implementation

Besides ACPI complaint disk and BIOS and a kernel withACPI support, our model needs a filter driver and powermanager. The power manager is capable of using the ACPIinterface to switch to sleep mode. The filter driver sits ontop of the IDE and SCSI disk device drivers. It sends readand write requests to the power manager executing at theuser-level. The power manager collects the traces fromthe filter driver and decides as to when to spin-down thedisk. The policies that we implemented are simple. Asemphasized earlier, this project provides a model for im-plementing complicated spin-down policies at the operat-ing system and user-level.

Filesystem Optimizations. The filesystem is another is-sue in the interaction between the hardware facilities forpower management and the system software. It is onething to turn off disk when it has been idle, but it is muchbetter to design a file system in such a way that it takesadvantage of the possibility of turning the disk off. Re-designing a filesystem for both power and performanceefficiency is way beyond the scope of this project. Hence,we propose two simple optimizations.

The first optimization is to tune bdflush and kupdate.Writes to disk are generally cached, and deferred. Twokernel threads handle deferred writes in Linux: bdflushand kupdate. bdflush updates the disk when the virtual

memory has trouble finding enough free memory to sat-isfy allocation requests. The second event that causes bd-flush to update disk is when the fraction of dirty buffersin the buffer cache exceeds a threshold. The other threadthat deals with flushing modified data to disk is kup-date. In normal usage, the kupdate periodically writesmodified buffers to the disk. All the values are set in/proc/sys/vm/bdflush. kupdate’s periodic updatepolicy spins-up the disk even when the dirty buffers areempty. Also, the default values (such as percentage ofbuffer cache dirty to activate bdflush, maximum numberof dirty blocks to write out per-wake-cycle) are overlyconservative in the Linux kernel. Our power manager,monitors disk activity. When there is no activity, the diskis spun down, kupdate is stopped, and bdflush dirty bal-ancing thresholds are increased from 30/60% to 80/90%.When disk activity is noticed again, kupdate is restarted,old bdflush values are restored. Having 80/90% dirty bal-ancing threshold might compromise reliability of file sys-tem, and can be tuned depending on the reliability neededdepending on the reliability needed.

The power manager is capable of listening to applica-tions. Our second optimization, allows applications totune themselves to conserve power, by classifying theirI/O operations into lazy and non-lazy I/O. Lazy I/O oper-ations such as a word processor saving files in the back-ground would be gathered up into clumps and done onlywhen the required I/O device is powered up for some otherreason. A non-lazy I/O request made when the requireddevice was powered down would cause the device to bepowered up immediately, the non-lazy I/O request to becarried out, and any pending lazy I/O operations to bedone. Such a policy requires knowing when I/O devicesare all powered up (which the power manager alreadyknows), knowing which application I/O requests are lazy,and being able to assure that such lazy I/O operations donot starve.

6.2 Results

The disk characteristics of the six traces we collected areshown in Figure 2. The graphs gives us a picture of thedisk activity (read and write) because of various runningapplications over time. The graphs are a scatter plot ofthe blocks accessed on Y axis over the time from the startof the trace on X axis. They give an idea of sleep timeavailable for disks.

Results of our implementation over ACPI are shown inTables 3 and 4. We report the number of disk shutdownswhen there is no activity, the sleep time which is the timethe disk spends in sleep mode, percentage increase in ac-cess time because of the shutdowns, power saved whencompared with a disk that never spins down, and with a

5

Blo

ck A

cces

sed

Time

(a) trace1

Blo

ck A

cces

sed

Time

(b) trace2

Blo

ck A

cces

sed

Time

(c) trace3

Blo

ck A

cces

sed

Time

(d) trace4

Blo

ck A

cces

sed

Time

(e) trace5

Blo

ck A

cces

sed

Time

(f) trace6

Figure 2: Read and Write characteristics of our Traces w.r.t Time

disk that is spun down based on the “conservative” APMpolicies. The implementation includes filesystem opti-mizations but does not include application-level tuning.Classification of I/O into lazy and non-lazy by applicationsrequires modifying application read and write calls. Wecould have modified the traces that we had, as it recordeddisk activities per application. But, we felt that the resultshence obtained may not be an accurate enough to be re-ported.

Trace Shutdowns Access Sleep Time Power Saved (%) Power Saved (%)(% Increase) (Secs) (wrt No spindown) (wrt APM)

trace1 38 1 28571 75 20trace2 7 1 2034 29 11trace3 6 1 1196 16 7trace4 25 3 3817 41 14trace5 34 1 10417 38 10trace6 27 2 9075 56 15

Table 3: Results for ACPI based Hard Disk spindown withfilesystem optimizations (timeout = 1 minute)

Trace Shutdowns Access Sleep Time Power Saved (%) Power Saved (%)(% Increase) (Secs) (wrt No spindown) (wrt APM)

trace1 31 1 27825 73 18trace2 3 0 1609 24 10trace3 2 0 844 11 7trace4 4 0 1732 19 13trace5 22 1 9253 34 9trace6 13 1 7720 49 12

Table 4: Results for ACPI based Hard Disk spindown withfilesystem optimizations (timeout = 3 minutes)

7 Temperature Sensitive Scheduler

Current day microprocessors have millions of transistorsand very high clock speeds and these numbers are still in-creasing. The amount of power dissipated by these com-ponents therefore assumes sizeable proportions and the is-sue needs to addressed at every possible level. The com-plexities introduced by the increasing number of compo-nents on the design of the system have been discussedin [20]. They can be divided broadly into two areas. Thefirst is the need to develop better thermal packaging to pre-vent overheating of the processor. The design of coolingdevices also has to take into account the worst case sce-nario in terms of power dissipation even though such casesmay occur very rarely. The second deals with complexitiesinvolving the delivery of power by the power distributionnetwork.

Temperature control is also a very desirable feature in lap-tops and embedded systems. The existence of special de-vices for cooling various components adds to the bulk, sizeand the power consumption of the system. Good thermalmanagement helps reduce the frequency at which these de-vices need to be operated and go a long way in improvingbattery life and reducing the amount of noise generated.

Temperature control is typically related to the power con-sumption of the system. The greater the power consumedby a component the higher the amount of heat generatedand, therefore, the greater the temperature of that compo-

6

nent. Power dissipation techniques at the circuit level havealready started reaching their limits. The importance ofthermal management continues to grow with the increas-ing levels of VLSI and clock frequencies. All these pointsto the fact that any further improvement in this area can beobtained only if the operating system and the applicationstake a proactive role in ensuring that the temperature ofthe system does not rise above a critical threshold.

In this section, we explore how the operating system canbe modified to incorporate temperature aware policies tobetter realize the goals of temperature control. Specifi-cally, we deal with modifying the scheduling policies ofoperating system so that the time quantum for which a“hot” process is scheduled is decreased whenever the am-bient temperature rises above a certain pre-defined thresh-old. The decrease in the available time quantum is propor-tional to the average temperature increase caused by thatprocess during its previous quanta and is calculated as anexponential weighted moving average.

7.1 Hardware and ACPI Support

The Intel Pentium III processor has a thermal sensor insideit to allow for thermal management. The thermal sensor isconnected to a thermal diode which is built into the proces-sor core. The core is one of the most significant sourcesof processor power dissipation. The temperature of thethermal diode provides the earliest indication of any vari-ation in processor temperature. The thermal sensor pro-vides data regarding the thermal state of the system andcan be used by software to take any action it deems fit.The information provided by the sensor has a very degreeof precision.The temperature information is not calibratedand different thresholds may be used for different operat-ing conditions.

The ACPI allows operating systems to be proactive in tak-ing decisions on the system thermal policies. The ACPIthermal design is based on thermal zones. Thermal zonesabstract subsets of the system whose thermal informationare of interest. The entire system may be defined to bea single thermal zone and thermal information relating toit may be obtained dynamically and used to influence op-erating system policy decisions. In our project, we usethermal management provided by the ACPI to obtain thetemperature of the system by defining the entire system asa single thermal zone.

7.2 Method

In this subsection, we present techniques for thermal con-trol at the level of the operating system. As an entity thatcan exercise control over application processes and alsoaccess the hardware, the operating system is in an ideal

position and is therefore the best place to implement tem-perature management policies that depend on controllingapplications on the basis of values obtained by monitoringthe hardware. Our approach was to modify the param-eters associated with processes dynamically on the basisof feedback obtained at run-time and use it to control theoverall parameters of the system.

Hardware

Normal Mode Reducing ModeTemperature

Scheduler

Applications

Kernel

ACPI

Proc

esso

r T

empe

ratu

re Switch ProcessorFrequency

Block Diagram describing the functioning of the temperaturesensitive scheduler

Figure 3: Temperature Sensitive Scheduler

In our approach (shown in Figure 3), the processor tem-perature is sampled continuously. This enables us to iden-tify hot processes. Whenever the temperature rises abovea certain threshold, the time quantum available for theexecution of process is reduced. The amount by whichthe scheduling quantum is cut down is proportional to theamount of heat the process is likely to generate if it were torun for a full quantum. In general, processes that are likelyto generate more heat will be penalized more than pro-cesses that are likely to generate less heat. Newly createdprocesses are assumed to produce no heat dissipation andare allowed to run a full time quantum during which theyare monitored before modifying their future time quanta.Typically, it is very difficult to predict the heat dissipationpatterns of processes in general and some sort of predic-tion mechanism is needed. We have based our predictionon the past power dissipation history of the process. Theamount of heat generated by a process during each quan-tum of its execution is monitored and the average heat dis-sipation, computed as the average increase in temperature,is calculated as an exponential weighted moving average.For example, if the temperature difference caused duringthe last execution of the process is τ inst, then the aver-age increase in temperature, τ , due to the execution of theprocess is given by

τ = α · τprev + β · τ inst

where α and β are parameters that determine the relativeweights that are accorded to previous temperature change

7

patterns and the current temperature change respectively.

We chose to have a moving average because we felt thatthe overall heat dissipation behavior of the process, ratherthan the instantaneous behavior, is a better indicator of theamount of heat it is likely to dissipate. If only the last tem-perature change was taken into account, it is possible thata hot process may get a higher time quantum on account ofits generating less heat during its reduced previous quan-tum. This policy will thus cause the generation of moreheat which, in turn, will increase the overall temperature ofthe system, thereby defeating our purpose. The weightedmoving average is used to determine the fraction of timequantum reduction that the process will be subjected to ifthe temperature rises above a certain pre-defined thresh-old. After the process has executed for this time period,the system idles for the duration of time which was takenaway from the process. This allows the microprocessorsome respite and a chance to lose some heat. When thetemperature eventually goes below the critical thresholdtemperature, the scheduler resumes functioning in the nor-mal manner, giving each process the full time quantum itwould normally get. The above policy ensures that pro-cesses that do not contribute to the heat dissipation are notaffected. In general, interactive processes will hardly no-tice any decrease in the scheduling time quantum. Theprocesses that are CPU bound and generate the maximumamount of heat will the ones that will undergo the maxi-mum reduction in the available time quantum for execu-tion.

The scheduler itself operates in two modes. In the nor-mal mode, the process which gets scheduled is allocated afixed time quantum and is allowed to run for the full du-ration of the time quantum. The scheduler executes in thismode when the ambient temperature of the system is lessthan a previously established critical value. In the secondmode of execution, the scheduler allocates varying timequanta to different processes based on the previously de-scribed technique. It may be noted that the actual decisionof which process gets to run next, based on the static nicepriority of the process and on a dynamic priority depend-ing on the age of the process, has not been modified. Onlythe time quantum of the process selected to run is alteredfor regulating the ambient temperature.

7.3 Implementation

We have modified the Linux kernel to incorporate intothe scheduling policy the above discussed mechanismsfor regulating the temperature of the microprocessor.The modifications were done to version Linux Ker-nel 2.4.14 with patch to support ACPI. The processscheduler of the Linux kernel is essentially implementedin two files, viz., kernel/sched.c which contains

the main implementation of the scheduler and in-clude/linux/sched.h which defines the task struc-ture. The task structure was modified to incorporate threemore variables:

The first variable, prevTemp, keeps track of the tempera-ture of the system before it begins execution for the currenttime quantum.

The second variable, currTemp, records the temperatureafter the process has finished execution for the current timequantum. The difference between currTemp and prevTempgives the amount of heat dissipated by the system duringthe execution of the process.

The third variable, aveTemp, stores the weighted averagetemperature change caused by the execution of the pro-cess. The parameters α and β described previously havebeen set to 0.8 and 0.2 respectively. This is to ensure thatsufficient importance is given to history and that any sud-den aberration in the detected processor temperature doesnot cause the system to oscillate. These values can bemodified depending on the importance attached to previ-ous heat dissipation behavior pattern.

The scheduling algorithm was modified as follows. If thetemperature of the system is less than the threshold tem-perature, the scheduler functions normally and gives theselected process a full time quantum to execute. The tem-perature of the system is monitored before and after thescheduling of each process and the changes are reflectedin their temperature parameters. If the temperature of thesystem exceeds the threshold temperature, the schedulertakes into account the heat dissipation of each process,as represented by the average temperature change causedby the process, while calculating the amount of time it isallowed to run. The reduction in time quantum is doneonly if the temperature exceeds a certain fixed threshold.The processor is allowed to idle for the remainder of thetime period which was snatched away from scheduled pro-cess so that it may have a chance to lower its temperature.Voltage scaling may also be done dynamically during thisphase to allow for a swift reduction in temperature. Oncethe temperature falls below the threshold, the scheduleragain switches to its normal mode of execution.

7.4 Results

We used computationally intensive tasks such as compil-ing a large number of C files using gcc compiler, datacompression using gzip and bzip2 to measure the ef-fectiveness of our technique. A high level application wasused to continuously monitor the temperature of systemat very small intervals of time. The application used the/proc interface exported by ACPI.

8

3050

3100

3150

3200

3250

3300

3350

0 200 400 600 800 1000

Tem

pera

ture

(un

calib

rate

d)

Time (in milli-seconds)

Variation of Processor Temperature with Time

"Modified""Unmodified"

Figure 4: Figure shows the variation of the processor tem-perature with time for an unmodified linux scheduler aswell as for the temperature sensitive scheduler. It can beseen from the graph that the temperature sensitive sched-uler is quite effective in maintaining the processor temper-ature around the given threshold.

The results are shown in the Figures 4 and 5. Figure 4shows the variation of the system temperature with respectto time. The x-axis shows the elapsed time in millisecondsand the y-axis shows the temperature of the processor at aparticular time instance. The temperature scale is uncali-brated. The results have been obtained for a temperaturethreshold of 3100. The variation of processor temperaturewith time has been plotted for both the modified (shownwith solid lines) and the unmodified version (shown withdashed lines) of the scheduler. In the case of the un-modified scheduler, the temperature of the system steadilyincreases till it stabilizes at a high value around 3330.Clearly, the unmodified scheduler is unable to control thevariation in processor temperature. On the other hand, themodified scheduler is effective in maintaining the temper-ature of the processor around the threshold value with asmall variance of 30 units. Whenever the temperature in-creases above the threshold value, the scheduler decreasesthe frequency of the processor, leading to a decrease intemperature. As can be seen from the graph, our strat-egy has been effective in controlling the temperature ofthe system.

Figure 5 shows how the performance of the system is af-fected by the threshold temperature. The threshold tem-perature at which the scheduler switches modes is plottedalong the x-axis and the time, in milliseconds, taken forthe completion of a fixed set of tasks is plotted along they-axis. When the threshold temperature is very low, thetime taken for task completion is very high. This is be-cause of the fact that, in this case, the scheduler switchesthe processor to a very low frequency for the most partof any given time quantum. As the threshold temperatureincreases, the completion time decreases and finally stabi-

lizes. The graph shows that the variation of processor uti-lization with threshold temperature is not linear. For verylow threshold values, a small change in the temperaturethreshold leads to drastic reduction in completion time andfor large threshold values, the completion time stabilizesand does not vary much.

30000

35000

40000

45000

50000

55000

60000

65000

70000

2000 2200 2400 2600 2800 3000 3200

Com

plet

ion

Tim

e (in

jiffi

es)

Threshold Temperature (uncalibrated)

Completion Time vs Threshold Temperature

"CompletionTime"

Figure 5: Figure shows the variation of completion time vsthreshold temperature. Note that the time for completionreduces steeply initially but the variation is less drastic asthe threshold temperature increases.

8 Related Work

Thermal Management. Previous work in thermal man-agement [12] has primarily focused on hardware and/orarchitectural techniques for reducing the amount of powerdissipation [26]. Brooks et. al [3] talks of how clockgating, a strategy used in pipeline design to eliminate un-wanted clock transitions, can lead to significant reductionin energy dissipation. Instruction scheduling is anotherarea for regulating the thermal state of the system at thearchitectural level. Toburen et. al [27] explore instructionscheduling for reducing energy dissipation.

In [25], the authors investigate a compilation methodcalled cold scheduling for scheduling instructions so thatswitching activity is minimized (which in turn, reducesheat dissipation). The goal of the instruction scheduler isto reorder the code so that switching activity is minimizedwithout a significant loss in performance. The reductionin switching activity can lead to reduction in power dissi-pation.

Various authors [1, 2] also describe techniques for dy-namic thermal control. The use of speculation control asa method for dynamic thermal management has been dis-cussed in [2]. Speculation control strategy seeks to placean upper bound on the number of unresolved branch de-codes that can exist simultaneously whenever the temper-ature of the processor junction rises above a certain trig-

9

ger value. Various architectural techniques such as clockfrequency scaling, voltage and frequency scaling [15], de-code throttling and I-cache toggling are described as ef-fective mechanisms for dynamic thermal management.

Software Strategies for Power Conservation. Mod-ification of key aspects of operating system policies [28]can maximize energy efficiency. Energy is a resource to bemanaged by the operating system. In addition to allocatingresources among competing tasks, operating systems arenow required to consider energy efficiency [4, 5, 7, 8, 19].The operating system should exert a high level controlover the energy usage policy and the interactions betweenthe applications and the operating system are required tomaintain this. This requirement brings in a fundamentalshift in the design of operating systems. Competing pro-cesses may be scheduled to receive a fair share of the bat-tery resources instead of the CPU. Applications which re-sort to heavy use of the disk should be accorded a lowerpriority. Emphasis needs to be placed on energy efficientresource management and operating system policies are tobe modified to keep pace with the new main memory tech-nologies such as the Direct Rambus DRAM (RDRAM)which have the ability to control the power state of indi-vidual memory chips.

The various low power modes of hardware componentsand issues relating to them have been dealt with in [17].Three software strategies for handling decision issues per-taining to these strategies and the suitability of each in dif-ferent situations have been described. Transition strategiesinvolve decisions on when to switch from one mode ofoperation to another. They usually require the characteris-tics of the devices’ various modes of operation and futurefunctionality requirements. This information is more eas-ily obtained compared to knowledge of future functional-ity requirements which are often determined using predic-tion strategies. These two pieces of information are usedto determine an inactivity threshold such that every timea component is idle for a period greater than its inactivitythreshold, it is switched to a low power mode. The loadchange strategy [17] modifies the functionality requiredfrom a particular hardware component in such a way thatthe component may frequently be put in a power savingmode. This is usually done by changing the load on thecomponent. Reordering disk requests, caching, etc., areexamples of this approach. Adaptation strategies [17] aimto modify software to enable power saving use of com-ponents. Each hardware component is treated separately,given the fact that the power and performance characteris-tics of each component varies.

In [16], the authors have explored methods for reducingthe power consumption of the CPU by turning it off whenit is not doing any useful work. They identify two prob-

lems with current processor time management policies.Operating systems may schedule processes even if theydon’t have anything to run. Further, processes runningin the foreground request the processor from time to timeeven if they are idle. The strategies put forth to overcomethese problems include the use of heuristics to detect ifan idle process is requesting the CPU frequently and, ifso, to forcibly prevent the process from getting scheduled.Event-driven models are also discussed, where processesmay be blocked whenever there is no event to be pro-cessed.

Power aware page allocation techniques [14] concentrateon extending the battery life of mobile devices by reduc-ing the energy consumption in main memory. The inter-action of page placement with both static and dynamichardware policies is used to effectively exploit the mem-ory power management features that modern memoriesprovide. The various page allocation policies that maybe used by an intelligent operating system to exploit thehardware strategies and the benefits of cooperative hard-ware/software policies to minimize the energy-delay prod-uct of main memory are discussed. Clustered page al-location is used to reduce the DRAM refresh rates andpages are compacted into the minimum number of inter-nal memory banks. This eliminates the need to refreshentire DRAM banks with no active pages.

Roy et. al [22] discusses various software optimizationsfor minimizing power consumption. They are done mainlyby selecting the least expensive instruction sequences,minimizing the frequency and (thereby) the cost of mem-ory accesses and exploiting the power management fea-tures of the hardware.

Hard-disk Spindown. Minimizing the power consump-tion of the disk [10] is very important to gain significantsavings. However, there is a tradeoff between the powerthat can be saved and the impact on response time. Tracesimulations [10] show the importance of controlling theCPU and the state of the disk to gain any significant sav-ings. Two types of algorithms are used for spinning a diskup and down — off-line and on-line. Off-line algorithmsuse future knowledge and provide a useful baseline forcomparing different on-line algorithms. They are based onthe relative costs of spinning the disk or starting it up. Onthe other hand, on-line algorithms rely on only past behav-ior and are implementable. Various predictive policies areused to interpret historic information to predict the nextaccess. However, simple threshold policies may be betterwhen access patterns are not sufficiently regular.

Adaptive spin down policies for disks [9] recognize thelimitations of having a fixed threshold for decisions onspinning down of disks. A small threshold may lead toinconvenience while a large threshold may not save en-

10

ergy. Usage patterns change over time as does the needfor energy conservation. Therefore, the spin-down thresh-old is dynamically decided by tuning it with the user’saccess patterns and priorities. Adaptive spin-down elim-inates a very significant portion of the disk spin-ups thatare considered inconvenient by the user while only slightlyincreasing the energy consumption. Spin down policieshave conflicting goals of reducing energy consumptionwhile preserving interactive response. Having a shortfixed threshold may sometimes increase energy consump-tion due to the frequent disk spin ups. Caching is em-ployed to minimize disk access requests. Adaptive spin-down policies monitor the spin-down threshold and adjustit to keep a balance between energy consumption and in-teractivity by eliminating undesirable spin-ups.

Application-Level Power Management. Energy awareadaptation [11] for mobile applications requires a collab-orative interaction between the applications and the oper-ating system for attaining user-specified goals for batteryduration. Applications change their behavior dynamicallyto conserve energy on the directive of the operating sys-tem. The operating system monitors the energy supplyand demand and selects the right tradeoff between energyconservation and application quality. As the decisions aremade dynamically, there is more accurate knowledge ofenergy supply and demand which allows better decisionsto be made.

9 Conclusion

Operating systems are largely unaware of the “power-saving” modes that hardware devices provide. Power-awareness at the application and the operating system levelwas previously not very easy because of lack of standard-ized interface at the hardware level. In this project, we pro-pose a model that exploits the new ACPI standards. Thissimple model allows “power-aware” policy decisions to bemade at the operating system and user level. We demon-strate this by implementing – (i) simple hard-disk spindown policy which on an average had 15% more powersavings that an APM (BIOS) based spin-down policy, (ii)a temperature sensitive scheduler that controls processortemperature.

References

[1] D. Brooks and M. Martonosi. Adaptive thermal man-agement for high-performance microprocessors. InWorkshop on Complexity Effective Design at ISCA,June 2000.

[2] D. Brooks and M. Martonosi. Dynamic thermalmanagement for high-performance microprocessors.In Proceedings of 7th International Symposium on

High-Performance Computer Architecture, January2001.

[3] David Brooks and Margaret Martonosi. Value-based clock gating and operation packing: dynamicstrategies for improving processor power and perfor-mance. ACM Transactions on Computer Systems,18(2):89–126, May 2000.

[4] Ellis S. C. Power management in notebook PCs. InProceedings of the Silicon Valley Personal Comput-ing Conference, pages 749–754, 1991.

[5] Ramon Caceres, Fred Douglis, Kai Li, and BrianMarsh. Operating system implications of solid-statemobile computers. In Fourth Workshop on Worksta-tion Operating Systems, October 1993.

[6] Compaq, Intel, Microsoft, Phoenix, and Toshiba.ACPI: Advanced configuration and power interface.2001.

[7] Julio L. da Siha Jr., Francky Catthoor, Diederik Verk-est, and Hugo De Man. Power exploration for dy-namic data types through virtual memory manage-ment refinement. In Proceedings of the InternationalSymposium on Low Power Electronics and Design(ISLPED-98), pages 311–316, August 1998.

[8] Robert P. Dick, Ganesh Lakshminarayana, AnandRaghunathan, and Niraj K. Jha. Power analysis ofembedded operating systems. In Proceedings of the37th Conference on Design Automation (DAC-00),pages 312–315, NY, June 5–9 2000. ACM/IEEE.

[9] Fred Douglis, P. Krishnan, and Brian Bershad. Adap-tive disk spin-down policies for mobile comput-ers. In USENIX Association, editor, Proceedingsof the second USENIX Symposium on Mobile andLocation-Independent Computing, pages 121–137.USENIX, April 1995.

[10] Fred Douglis, P. Krishnan, and Brian Marsh. Thwart-ing the power-hungry disk. Technical Report MITL-TR-61-93, Matasushia Information Technology Lab-oratory, July 1993.

[11] Jason Flinn and M. Satyanarayanan. Energy-awareadaptation for mobile application. In Proceedingsof the 17th ACM Symposium on Operating Sys-tems Principles (SOSP’99), pages 48–63, December1999.

[12] R. Gonzalez and M. Horowitz. Energy dissipation ingeneral purpose microprocessors. In IEEE Jounralof Solid-State Circuits, volume 31, 1996.

11

[13] Tom R. Halfhill. Transmeta breaks x86 low powerbarrier. Microprocessor Report, 14(2):1, 9–18, 2000.

[14] Alvin Lebeck, Xiaobo Fan, Heng Zeng, and CarlaEllis. Power aware page allocation. ACM SIGPLANNotices, 35(11):105–116, November 2000.

[15] J. Lorch and A. Smith. Improving dynamic voltagescaling algorithms with pace. In ACM SIGMETRICS2001, June 2001.

[16] Jacob R. Lorch and Alan Jay Smith. Reducing pro-cessor power consumption by improving processortime management in a single-user operating system.Technical Report CSD-96-914, University of Cali-fornia, Berkeley, September 3, 1996.

[17] Jacob R. Lorch and Alan Jay Smith. Softwarestrategies for portable computer energy manage-ment. Technical Report CSD-97-949, University ofCalifornia, Berkeley, June 13, 1997.

[18] Y. H. Lu, T. Simunic, and G. De Micheli. Softwarecontrolled power management. In Proceedings of the7th International Workshop on Hardware/SoftwareCodesign (CODES99), pages 157–161, New York,May 3–5 1999. ACM Press.

[19] J. MacDonald. Power management for 386 dxl-based notebook computers. In Proceedings of the Sil-icon Valley Personal Computers Conference, 1991.

[20] E. Rohou and Smith M. D. Dynamically managingprocessor temperature and power. In 2nd Workshopof Feedback Directed Optimization, November 1999.

[21] Drew Roselli, Jacob R. Lorch, and Thomas E. An-derson. A comparison of file system workloads. InProceedings of the 2000 USENIX Annual Technical

Conference (USENIX-00), pages 41–54, Berkeley,CA, June 18–23 2000. USENIX Ass.

[22] K Roy and M. C Johnson. Software design forlow power. In Advanced Study Institute on LowPower Design in Deep Submicron Electronics, Au-gust 1996.

[23] Chris Ruemmler and John Wilkes. UNIX disk accesspatterns. In USENIX Association, editor, Proceed-ings of the Winter 1993 USENIX Conference, pages405–420, Winter 1993.

[24] Tajana Simunic, Luca Benini, Peter Glynn, and Gio-vanni De Micheli. Dynamic power management forportable systems. In Proceedings of the 6th AnnualInternational Conference on Mobile Computing andNetworking (MOBICOM-00), pages 11–19, N. Y.,August 6–11 2000. ACM Press.

[25] C. L Su, C. Y Tsui, and A. M Despain. Low powerarchitecture design and compilation techniques forhigh-performance processors. In IEEE COMPCON,February 1994.

[26] V. Tiwari, D. Singh, S. Rajgopal, G. Mehta, andR Patel. Reducing power in high-performance mi-croprocessors. In 35th Design Automation Confer-ence, 1998.

[27] M. C Toburen and T. M Conte. Instruction schedul-ing for low power dissipation in high performancemicroprocessors. Technical report, North CarolinaState University, May 1998.

[28] A. Vahdat, A. R Lebeck, and C. S Ellis. Every joulsis previous: The case for revisiting operating systemdesign for energy efficiency. In Ninth ACM SIGOPSEuropean Workshop, September 2000.

12