Electrical computers and digital processing systems: support – Computer power control – Power conservation
Reexamination Certificate
2000-07-07
2003-08-19
Heckler, Thomas M. (Department: 2181)
Electrical computers and digital processing systems: support
Computer power control
Power conservation
Reexamination Certificate
active
06609208
ABSTRACT:
BACKGROUND
1. Field of Invention
The present invention relates generally to energy usage profiling, and more particularly, to the energy-based sampling of computing resources in order to profile energy consumption.
2. Background of the Invention
Limited battery life is a well-known problem with portable computers. Since batteries can store only a limited amount of engergy, energy is a critical resource for portable computers. In order to optimize software for reduced energy consumption and extended battery life, it is important to understand how energy consumption is affected by program behavior. System and software designers need to understand how program execution affects energy consumption. Ideally, these designers would like to attribute energy consumption to specific software components such as applications, processes, or even individual functions and operations.
Such detailed information would facilitate manual or automated identification of the code sequences that account for a significant portion of the overall energy consumption. It also would facilitate manual or automatic optimizations to be applied to these sequences with the aim of reducing overall energy consumption and extending battery life. Some optimizations may involve replacing particular code sequences with more energy-efficient alternatives. Other optimizations may also involve algorithmic changes. For example, to detect the occurrence of asynchronous events, it is often more energy efficient to use interrupts than to busy wait. However, because it is easier to write a program to use busy waiting, designers may wish to only use interrupts where doing so would save a noteworthy amount of energy. The method in which applications interact can also incur an energy cost. For example, a poorly designed synchronization mechanism may result in applications that, while accessing a shared resource, spend a lot of time unnecessarily waiting and hence waste energy. Finally, the design of the operating system can also impact the energy consumed by both itself and applications running on top of it. For example, in a multitasking operating system, a poorly chosen timeslice interval may cause unnecessary context switches or cache flushes.
Statistical sampling is a well-known technique for monitoring the performance of software systems. Sampling-based systems, such as Compaq's™ Continuous Profiling Infrastructure (DCPI), statistically estimate the number of events associated with regions of code, such as the number of cycles spent executing a function, or the data cache miss rate of a load instruction. This type of sampling-based system is described further in U.S. Pat. No. 5,796,939, entitled “High Frequency Sampling of Processor Performance Counters,” issued Aug. 18, 1998, the subject matter of which is herein incorporated by reference in its entirety. To support such sampling profilers, many processors contain specialized hardware to count events and generate an interrupt after a specified number of events have occurred. For example, the Compaq™ Alpha 21164 microprocessor can count dozens of events, including processor cycles, fetched or executed instructions, data or instruction cache misses, and translation lookaside buffer (TLB) misses.
Assuming that interrupts are delivered promptly, the number of event-based samples associated with a program location (i.e., the interrupted program counter address, or PC) will be proportional to the total number of events that occurred at that location. For example, in DCPI profiles, instructions that take longer to execute will accumulate proportionally more “cycles” events, and instructions that miss more often in the instruction cache will accumulate proportionally more “imiss” events.
Although statistical sampling of program structures is well known, these statistical sampling techniques do not provide a mechanism by which the energy consumed by a program may be mapped to specific software components. For the reasons noted above, it would be desirable to extend the functionality provided by DCPI and other monitoring systems to the domain of energy profiling.
A prior art approach to mapping energy consumption to software components is given by Jason Flinn and M. Satyanarayanan in, “PowerScope: A Tool for Profiling the Energy Usage of Mobile Applications”, Proceedings of the 2
nd
IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, La., Feb. 25-26, 1999 (“PowerScope”). PowerScope profiles the power consumed by applications running on a computer system by using an external digital multimeter and a second computer for data collection. To begin profiling, the data collection computer configures the multimeter to generate a trigger at fixed time intervals. Each time the trigger occurs, an interrupt-service request is registered with the computer being profiled. When this computer subsequently services the interrupt, software running on the computer collects a sample containing the current process ID (PID) and program counter address (PC). Before a trigger is generated, however, the multimeter measures and records the amount of electrical current being drawn by the profiled computer, since variations in the supply voltage were found to be small. The instantaneous current reading is then transferred asynchronously to the software running on the data collection computer.
Once profiling has been completed, the current readings and PID/PC samples are processed. PowerScope first estimates the energy consumption during each time interval. The estimate assumes that each instantaneous current reading represents the average amount of current drawn during the corresponding interval. Accordingly, the energy consumed during an interval is estimated as the product of the length of the time interval, the current reading for the interval, and the predetermined and assumed constant value of the supply voltage. Next, PowerScope correlates these estimates with the PID/PC samples.
The PowerScope profiling approach of time-based instantaneous power measurements has several significant disadvantages, including a lack of simplicity, accuracy, and efficiency. The PowerScope system design is cumbersome. For instance, PowerScope requires an external digital multimeter, connected to a second, separate computer system that records energy readings. It would be more practical and less expensive to have a simpler system that could be incorporated into the computer system of interest.
The PowerScope approach also introduces two potential sources of inaccuracy. First, the sampling interval is based on time, and the energy measurements reflect only the instantaneous power usage when samples are taken. PowerScope assumes that the cumulative energy over the interval can be computed as the product of the interval duration and the instantaneous power measurement. However, this assumption is suspect, since application power consumption varies over time, and is not necessarily correlated with time.
The large variation in power consumption over time is illustrated by the power usage graph shown in FIG.
3
. This graph plots the power consumed by an Itsy Pocket Computer from Compaq™ as the Linux operating system is booted and several applications are run. The power data in
FIG. 3
was obtained by measuring 50 times a second the current supplied to the Itsy and the supply voltage. As shown in
FIG. 3
, the power consumed fluctuates between approximately 0.2-1.8 watts.
Second, to avoid significant distortion from the power consumption of the interrupt handler that runs on the system being profiled, PowerScope delays the interrupt until after the multimeter has finished making its instantaneous power reading. By so doing, a significant amount of skew is introduced between the meter and the computer being profiled. This skew is sufficient that PowerScope cannot be used to accurately map energy consumption to program structures any smaller than a procedure.
PowerScope records energy measurements and program location samples separately (in fact, on different computers), and the separate sets of data are
Farkas Keith I.
Waldspurger Carl A.
Heckler Thomas M.
Hewlett-Packard Development Company
LandOfFree
Energy-based sampling for performance monitoring does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Energy-based sampling for performance monitoring, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Energy-based sampling for performance monitoring will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3121214