Predicting energy savings

A mechanism is provided for estimating energy/power consumption of a fixed-frequency operating mode while system is running in dynamic power management mode. For each time interval in a plurality of time intervals within a time period: a first processor identifies a modeled total nominal power value for at least one second processor during a current time interval, stores the modeled total nominal power value for the current time interval in a storage, identifies a dynamic power management mode power value for the at least one second processor in the data processing system during the current interval, and stores the dynamic power management mode power value for the current time interval in the storage. Responsive to the time period expiring, a comparison is produced of a plurality of modeled total nominal power values and a plurality of dynamic power management mode power values over the time period.

BACKGROUND

The present application relates generally to an improved data processing apparatus and method and more specifically to mechanisms for predicting energy savings.

As computer and other electronic systems have increased performance over time, the power consumed to enable the performance has increased dramatically. Performance optimization has long been the goal of different architectural and systems software studies, driving technological innovations to the limits for getting the most out of every cycle. This quest for performance has made it possible to incorporate millions of transistors on a very small die, and to clock these transistors at very high speeds. While these innovations and trends have helped provide tremendous performance improvements over the years, they have at the same time created new problems that demand immediate consideration.

SUMMARY

In one illustrative embodiment, a method, in a data processing system, is provided for estimating energy/power consumption of a fixed-frequency operating mode while system is running in dynamic power management mode. For each time interval in a plurality of time intervals within a time period the illustrative embodiment identifies a modeled total nominal power value for at least one processor in the data processing system during a current time interval, stores the modeled total nominal power value for the current time interval in a storage, identifies a dynamic power management mode power value for the at least one processor in the data processing system during the current interval; and store the dynamic power management mode power value for the current time interval in the storage. In the illustrative embodiments, for the plurality of time intervals, a plurality of modeled total nominal power values and a plurality of dynamic power management mode power values are stored. Then, responsive to the time period expiring, the illustrative embodiment produces a comparison of the plurality of modeled total nominal power values and the plurality of dynamic power management mode power values over the time intervals in the plurality of time intervals in the time period.

DETAILED DESCRIPTION

Currently, there is no means for a customer to understand cost savings from a dynamic power management policy operation over a traditional fixed-frequency operation without running workloads in both modes, measuring the power, and manually computing the savings. Therefore, the illustrative embodiments provide a mechanism for predicting energy savings over a nominal fixed-frequency power management mode using run-time measurements under a variable-frequency dynamic-power management policy mode. In the illustrative embodiments, system characterization with benchmark workloads is performed to extract a model of different power components' relationship with activities, temperature, and idle power. At run time, in the variable-frequency power saving mode, the model is used to calculate total system power at fixed nominal frequency, which is then subtracted from actual power measurement to find power savings at each moment. The savings may then be integrated over time to calculate a total energy saving of power-saving mode.

With reference now to the figures,FIG. 1is a block diagram of an example data processing system in which aspects of the illustrative embodiments may be implemented. Data processing system100is an example of a computer in which computer usable code or instructions implementing the processes for illustrative embodiments of the present invention may be located. In the depicted example, data processing system100employs a hub architecture including north bridge and memory controller hub (NB/MCH)102and south bridge and input/output (I/O) controller hub (SB/ICH)104. Processing unit106, main memory108, and graphics processor110are connected to NB/MCH102. Graphics processor110may be connected to NB/MCH102through an accelerated graphics port (AGP).

In the depicted example, local area network (LAN) adapter112connects to SB/ICH104. Audio adapter116, keyboard and mouse adapter120, modem122, read only memory (ROM)124, hard disk drive (HDD)126, CD-ROM drive130, universal serial bus (USB) ports and other communication ports132, and PCI/PCIe devices134connect to SB/ICH104through bus138and bus140. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM124may be, for example, a flash basic input/output system (BIOS).

An operating system runs on processing unit106. The operating system coordinates and provides control of various components within the data processing system100inFIG. 1. As a client, the operating system may be a commercially available operating system such as Microsoft® Windows 7®. An object-oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java™ programs or applications executing on data processing system100.

As a server, data processing system100may be, for example, an IBM® eServer™ System p® computer system, running the Advanced Interactive Executive (AIX®) operating system or the LINUX® operating system. Data processing system100may be a symmetric multiprocessor (SMP) system including a plurality of processors in processing unit106. Alternatively, a single processor system may be employed.

Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as HDD126, and may be loaded into main memory108for execution by processing unit106. The processes for illustrative embodiments of the present invention may be performed by processing unit106using computer usable program code, which may be located in a memory such as, for example, main memory108, ROM124, or in one or more peripheral devices126and130, for example.

A bus system, such as bus138or bus140as shown inFIG. 1, may be comprised of one or more buses. Of course, the bus system may be implemented using any type of communication fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communication unit, such as modem122or network adapter112ofFIG. 1, may include one or more devices used to transmit and receive data. A memory may be, for example, main memory108, ROM124, or a cache such as found in NB/MCH102inFIG. 1.

Referring toFIG. 2, an exemplary block diagram of a conventional dual threaded processor design showing functional units and registers is depicted in accordance with an illustrative embodiment. Processor200may be implemented as processing unit106inFIG. 1in these illustrative examples. Processor200comprises a single integrated circuit superscalar microprocessor with dual-thread simultaneous multi-threading (SMT) that may also be operated in a single threaded mode. Accordingly, as discussed further herein below, processor200includes various units, registers, buffers, memories, and other sections, all of which are formed by integrated circuitry. Also, in an illustrative embodiment, processor200operates according to reduced instruction set computer (RISC) techniques.

As shown inFIG. 2, instruction fetch unit (IFU)202connects to instruction cache204. Instruction cache204holds instructions for multiple programs (threads) to be executed. Instruction cache204also has an interface to level 2 (L2) cache/memory206. IFU202requests instructions from instruction cache204according to an instruction address, and passes instructions to instruction decode unit208. In an illustrative embodiment, IFU202may request multiple instructions from instruction cache204for up to two threads at the same time. Instruction decode unit208decodes multiple instructions for up to two threads at the same time and passes decoded instructions to instruction sequencer unit (ISU)209.

Processor200may also include issue queue210, which receives decoded instructions from ISU209. Instructions are stored in the issue queue210while awaiting dispatch to the appropriate execution units. For an out-of order processor to operate in an in-order manner, ISU209may selectively issue instructions quickly using false dependencies between each instruction. If the instruction does not produce data, such as in a read after write dependency, ISU209may add an additional source operand (also referred to as a consumer) per instruction to point to the previous target instruction (also referred to as a producer). Issue queue210, when issuing the producer, may then wakeup the consumer for issue. By introducing false dependencies, a chain of dependent instructions may then be created, whereas the instructions may then be issued only in-order. ISU209uses the added consumer for instruction scheduling purposes and the instructions, when executed, do not actually use the data from the added dependency. Once ISU209selectively adds any required false dependencies, then issue queue210takes over and issues the instructions in order for each thread, and outputs or issues instructions for each thread to execution units212,214,216,218,220,222,224,226, and228of the processor. This process will be described in more detail in the following description.

In an illustrative embodiment, the execution units of the processor may include branch unit212, load/store units (LSUA)214and (LSUB)216, fixed point execution units (FXUA)218and (FXUB)220, floating point execution units (FPUA)222and (FPUB)224, and vector multimedia extension units (VMXA)226and (VMXB)228. Execution units212,214,216,218,220,222,224,226, and228are fully shared across both threads, meaning that execution units212,214,216,218,220,222,224,226, and228may receive instructions from either or both threads. The processor includes multiple register sets230,232,234,236,238,240,242,244, and246, which may also be referred to as architected register files (ARFs).

An ARF is a file where completed data is stored once an instruction has completed execution. ARFs230,232,234,236,238,240,242,244, and246may store data separately for each of the two threads and by the type of instruction, namely general purpose registers (GPRs)230and232, floating point registers (FPRs)234and236, special purpose registers (SPRs)238and240, and vector registers (VRs)244and246. Separately storing completed data by type and by thread assists in reducing processor contention while processing instructions.

The processor additionally includes a set of shared special purpose registers (SPR)242for holding program states, such as an instruction pointer, stack pointer, or processor status word, which may be used on instructions from either or both threads. Execution units212,214,216,218,220,222,224,226, and228are connected to ARFs230,232,234,236,238,240,242,244, and246through simplified internal bus structure249.

In order to execute a floating point instruction, FPUA222and FPUB224retrieves register source operand information, which is input data required to execute an instruction, from FPRs234and236, if the instruction data required to execute the instruction is complete or if the data has passed the point of flushing in the pipeline. Complete data is data that has been generated by an execution unit once an instruction has completed execution and is stored in an ARF, such as ARFs230,232,234,236,238,240,242,244, and246. Incomplete data is data that has been generated during instruction execution where the instruction has not completed execution. FPUA222and FPUB224input their data according to which thread each executing instruction belongs to. For example, FPUA222inputs completed data to FPR234and FPUB224inputs completed data to FPR236, because FPUA222, FPUB224, and FPRs234and236are thread specific.

During execution of an instruction, FPUA222and FPUB224output their destination register operand data, or instruction data generated during execution of the instruction, to FPRs234and236when the instruction has passed the point of flushing in the pipeline. During execution of an instruction, FXUA218, FXUB220, LSUA214, and LSUB216output their destination register operand data, or instruction data generated during execution of the instruction, to GPRs230and232when the instruction has passed the point of flushing in the pipeline. During execution of a subset of instructions, FXUA218, FXUB220, and branch unit212output their destination register operand data to SPRs238,240, and242when the instruction has passed the point of flushing in the pipeline. Program states, such as an instruction pointer, stack pointer, or processor status word, stored in SPRs238and240indicate thread priority252to ISU209. During execution of an instruction, VMXA226and VMXB228output their destination register operand data to VRs244and246when the instruction has passed the point of flushing in the pipeline.

Data cache250may also have associated with it a non-cacheable unit (not shown) which accepts data from the processor and writes it directly to level 2 cache/memory206. In this way, the non-cacheable unit bypasses the coherency protocols required for storage to cache.

In response to the instructions input from instruction cache204and decoded by instruction decode unit208, ISU209selectively dispatches the instructions to issue queue210and then onto execution units212,214,216,218,220,222,224,226, and228with regard to instruction type and thread. In turn, execution units212,214,216,218,220,222,224,226, and228execute one or more instructions of a particular class or type of instructions. For example, FXUA218and FXUB220execute fixed point mathematical operations on register source operands, such as addition, subtraction, ANDing, ORing and XORing. FPUA222and FPUB224execute floating point mathematical operations on register source operands, such as floating point multiplication and division. LSUA214and LSUB216execute load and store instructions, which move operand data between data cache250and ARFs230,232,234, and236. VMXA226and VMXB228execute single instruction operations that include multiple data. Branch unit212executes branch instructions which conditionally alter the flow of execution through a program by modifying the instruction address used by IFU202to request instructions from instruction cache204.

Instruction completion unit254monitors internal bus structure249to determine when instructions executing in execution units212,214,216,218,220,222,224,226, and228are finished writing their operand results to ARFs230,232,234,236,238,240,242,244, and246. Instructions executed by branch unit212, FXUA218, FXUB220, LSUA214, and LSUB216require the same number of cycles to execute, while instructions executed by FPUA222, FPUB224, VMXA226, and VMXB228require a variable, and a larger number of cycles to execute. Therefore, instructions that are grouped together and start executing at the same time do not necessarily finish executing at the same time. “Completion” of an instruction means that the instruction is finishing executing in one of execution units212,214,216,218,220,222,224,226, or228, has passed the point of flushing, and all older instructions have already been updated in the architected state, since instructions have to be completed in order. Hence, the instruction is now ready to complete and update the architected state, which means updating the final state of the data as the instruction has been completed. The architected state can only be updated in order, that is, instructions have to be completed in order and the completed data has to be updated as each instruction completes.

Instruction completion unit254monitors for the completion of instructions, and sends control information256to ISU209to notify ISU209that more groups of instructions can be dispatched to execution units212,214,216,218,220,222,224,226, and228. ISU209sends dispatch signal258, which serves as a throttle to bring more instructions down the pipeline to the dispatch unit, to IFU202and instruction decode unit208to indicate that it is ready to receive more decoded instructions. While processor200provides one detailed description of a single integrated circuit superscalar microprocessor with dual-thread simultaneous multi-threading (SMT) that may also be operated in a single threaded mode, the illustrative embodiments are not limited to such microprocessors. That is, the illustrative embodiments may be implemented in any type of processor using a pipeline technology.

Moreover, the data processing system100may take the form of any of a number of different data processing systems including client computing devices, server computing devices, a tablet computer, laptop computer, telephone or other communication device, a personal digital assistant (PDA), or the like. In some illustrative examples, data processing system100may be a portable computing device that is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data, for example. Essentially, data processing system100may be any known or later developed data processing system without architectural limitation.

FIG. 3depicts a high-level view of fixed-frequency characterization and modeling to estimate energy/power consumption of a fixed-frequency operating mode while system is running in dynamic power management mode in accordance with an illustrative embodiment. Data processing system300comprises management control logic302and characterization and modeling logic304. In order to obtain characterization data and real-time data for each of processors318in data processing system300, management control logic302interacts with activity proxy logic306, power sensor(s)308, thermal sensor(s)310, utilization sensor(s)312, revolution per minute (RPM) sensor(s)314, or the like.

Power sensors308monitor the power consumed by each of the processors and each of cooling fans320and send the detected system aggregated activity estimate values to management control logic302. Likewise, utilization sensors312may monitor the workload performed by each of processors318and send detected utilization values to management control logic302. Similarly, thermal sensors310may be positioned adjacent to areas within data processing system300that typically experience the greatest variance in temperature during the execution of most applications, such as adjacent to each of processors318. Thermal sensors310monitor the temperature associated with these areas and send the detected temperature values to management control logic302. Additionally, thermal sensors310may be directed to measuring both an ambient temperature of data processing system300as well as extreme localized temperature areas of data processing system300, such as those used in the illustrative embodiments, which may comprise: adjacent to each processing unit, memory flow controller, disks, or the like. RPM sensors314may monitor the revolutions per minute (RPMs) of cooling fans320and send detected RPM values to management control logic302.

At a high level, characterization and modeling logic304receives real-time aggregated activity estimate values for each processor within data processing system300via management control logic302and activity proxy logic306that indicate that power being used by each processor in executing activities of a workload. For each processor, characterization and modeling logic304multiples the aggregated activity estimate value with a frequency scaling factor, which calculated by dividing a real-time measured frequency value divided by a specified fixed-frequency value. The specified fixed-frequency value is a frequency value of a desired fixed-frequency mode specified by a user of data processing system300in order to determine a difference between the fixed-frequency mode and a current operating mode of data processing system300. By characterization and modeling logic304multiplying with the aggregated activity estimate value with the frequency scaling factor, characterization and modeling logic304obtains a frequency-scaled activity proxy counter value which is indicative of the activities being executed by the processors within data processing system300as a value of the specified fixed-frequency value.

Using vital processor data that is provided by the manufacturer and/or calculated at deployment time of data processing system300and stored in storage316, characterization and modeling logic304determines a slope of for the processor as shipped (slope_shipped) and utilizes this value as a power scaling factor. Characterization and modeling logic304multiplies power scaling factor with the frequency-scaled activity proxy counter value to obtain a modeled active power value. Based on a current operating temperature of data processing system300obtained via management control logic302from temperature sensors310, characterization and modeling logic304identifies a shipped temperature dependent idle power value from a data structure of temperature dependent idle processor power values stored in storage316. As will be described in detail below, the data structure of temperature dependent idle processor power values is generated by management control logic302during an initialization phase of data processing system300when no workload is being executed.

Characterization and modeling logic304adds the identified temperature dependent idle processor power value to the modeled active power value to obtain a modeled processor power value. In order to obtain a modeled total nominal power value for data processing system300during the current time interval, characterization and modeling logic304adds the modeled processor power value for each processor in data processing system300, a measured fan power value for the current time interval (described in detail below), as well as other measured power values associated with power consuming devices in data processing system300, such as memory device power, input/output (I/O) device power, service processor power, or the like. Characterization and modeling logic304stores the modeled total nominal power value for the current interval in storage316.

In order to provide a comparison of determined modeled total nominal power values in relation to the dynamic power management mode value, for each time interval, management control logic302determines a dynamic power management mode power value, which management control logic302also stores in storage316associated with the modeled processor power value of the same time interval. In order to determine dynamic power management mode power value, management control logic302implements logic in a final power model that provides run-time fixed-frequency power estimation in the dynamic power saving mode.

For each subsequent time interval, characterization and modeling logic304again determines a new modeled total nominal power value and management control logic302determines a dynamic power management mode power value. During each subsequent operation, the temperature of data processing system300will rise and fall with the work being performed which not only effects the temperature dependent idle power value but all the fan power value as the fan speed will change with the temperature change. Thus, characterization and modeling logic304stores the modeled total nominal power value for the current interval in storage316and management control logic302stores the determined dynamic power management mode power value in storage316associated with the modeled processor power value of the same time interval.

Finally, once characterization and modeling logic304stores a plurality of modeled total nominal power values and management control logic302stores a plurality of dynamic power management mode power values for a specified time period, characterization and modeling logic304and/or management control logic302may provide a comparison of the plurality of modeled total nominal power values and the plurality of dynamic power management mode power values to the user such as through a graphical representation, a numerical representation, or the like.

FIG. 4depicts a detailed view of fixed-frequency characterization and modeling to estimate energy/power consumption of a fixed-frequency operating mode while system is running in dynamic power management mode in accordance with an illustrative embodiment. Data processing system400, which is similar to data processing300ofFIG. 3, comprises management control logic402and characterization and modeling logic404. In order to obtain characterization data and real-time data for each processor in data processing system400, management control logic402interacts with activity proxy logic406, power sensor(s)408, thermal sensor(s)410, utilization sensor(s)412, revolution per minute (RPM) sensor(s)414, or the like.

Power sensors408monitor the power consumed by each of the processors and each of cooling fans420and send the detected system aggregated activity estimate values to management control logic402. Likewise, utilization sensors412may monitor the workload performed by each of processors418and send detected utilization values to management control logic402. Similarly, thermal sensors410may be positioned adjacent to areas within data processing system400that typically experience the greatest variance in temperature during the execution of most applications, such as adjacent to each of processors418. Thermal sensors410monitor the temperature associated with these areas and send the detected temperature values to management control logic402. Additionally, thermal sensors410may be directed to measuring both an ambient temperature of data processing system400as well as extreme localized temperature areas of data processing system400, such as those used in the illustrative embodiments, which may comprise: adjacent to each processing unit, memory flow controller, disks, or the like. RPM sensors414may monitor the revolutions per minute (RPMs) of cooling fans420and send detected RPM values to management control logic402.

In order to obtain the real-time aggregated activity estimate values for each processor within data processing system400, during the execution of applications or software on data processing system400, management control logic402monitors various conditions associated with a set of components on each of processors418. Each of processors418comprises power manager422and chiplets430and440. A chiplet is a processor core plus some memory cache, such as an L2, L3, or L4 memory cache, or some combination thereof. Chiplet430comprises core432, L2 cache434, L3 cache436, and activity proxy logic406. Chiplet440comprises core442, L2 cache444, L3 cache446, and activity proxy logic406. WhileFIG. 4illustrates processors418as comprising two (2) chiplets and two levels of memory cache, alternate illustrative embodiments contemplate processors418as comprising any number of chiplets and memory caches, from one to several.

In some illustrative embodiments, activity proxy logic406track activity metrics on a per-chiplet basis, while in other illustrative embodiments, activity proxy logic406track the metrics on a per thread basis. Activity counters within each of activity proxy logic406track activities in cores432and442, L2 cache434and444, and L3 cache436and446, respectively, and reset on activity read from the activity proxy logic. Each of activity proxy logic406counts each of these activities in a counter. Activity proxy logic406multiplies the individual counts by a dynamically set weight factor specific to that particular activity to reach a value and store the value in an activity counter. A description of how the various weights associated with the various activity counters are dynamically determined and set will be described in detail below. A weight may be any value other than zero. In an illustrative embodiment, the weight factor comprises four bits. In other illustrative embodiments, the weight factor may be comprised of any number of bits.

Activity proxy logic406monitors a set of counters. Whenever an activity specified to be monitored occurs, activity proxy logic406adds a value equal to a dynamically set weight associated with the activity to a counter. The counter is associated with one activity only. Then, periodically, the values held in the set of counters monitored by activity proxy logic406are collected by activity proxy logic406. Activity proxy logic406each add these collected values together to arrive at an aggregated activity estimate value for the unit monitored by each of activity proxy logic406. Activity proxy logic406sends these aggregated activity estimate values to power manager422and then onto management control logic402.

Each of activity proxy logic406manages a set of counters. The activity proxy logic collects the stored values for the set of counters the activity proxy logic manages in parallel. Further, a single power manager manages a set of activity proxy logic. Each activity proxy has one or more units assigned that the activity proxy logic monitors. The activity proxy logic may then collect values in parallel or independently of each other. Further, the collection period is configurable for each activity proxy logic, and each activity proxy logic may collect the stored values for different periods than every other activity proxy managed by a power manager.

Power manager422and activity proxy logic406have memory and a dynamic control module that provides for assigning what specific counters will count what specific activities as well as dynamically determining and setting the weight to the activity based on either phases of application execution, types of application being executed, performance of applications being executed, or the like. As is illustrated above, one of the key programmable elements of the activity proxy architecture is the weight assigned to each activity count. For example, in the case where power is defined as P=Σ(Wi*Ai)+C, where Ai is an activity count, Wi is the associated weight, and C is a constant that may be added, rather than the weights being static as is known in current activity proxy architectures, in the illustrative embodiments each of weights (Wi) may be dynamically programmed based on the feedback gathered from the program during run-time. Such a scheme has the advantage of improving accuracy of the activity proxy architecture. Additionally, in order to dynamically tune the activity proxy architecture during run-time, the illustrative embodiments may use different models for activity proxy architecture. That is, assuming an underlying hardware where different models of power approximation are implemented, the dynamic approach may also decide which model to use to have better accuracy. For example, one model may be a linear combination of activity counts such as Σ(Wi*Ai)+C, where a second model may be a combination of linear and non-linear activity counts such as W1*A1+W2* log(A2)+C. Depending on the model type, a better fit may be possible and the dynamic approach decides which model to use depending on the program phase.

FIG. 5depicts one example where a selection of a plurality of predetermined weights and a plurality of predetermined constants is made based on conditions within the data processing system in accordance with an illustrative embodiment. For simplicity, this example approximates chiplet activity502from three activity counters504a,504b, and504c, three dynamically selected weights506a,506b, and506c, and one dynamically selected constant value508. In data processing system500, control logic510, from a finite state machine (not shown) of the activity proxy logic, such as activity proxy logic406ofFIG. 4, receives inputs that correlate to conditions related to the application being executed on the specific core to which the activity proxy logic is associated, such as instructions completed per cycle, number of threads in operation, voltage, temperature, voltage leakage, or the like. During execution of the application, control logic510receives the input, for example, instructions completed per cycle related to the application being executed. Control logic510then determines which weight from a plurality of predetermined weights and which constant from a plurality of predetermined constants should be selected based on the received instructions completed per cycle. That is, for each of activity counters504a,504b, and504c, there are four possible predetermined weights512that may be used for power approximation as well as four possible predetermined constants516that may be added to the power approximation. Weights Wy1, Wz1, Wc1, and Wd1are associated with activity counter504a, weights Wy2, Wz2, Wc2, and Wd2are associated with activity counter504b, weights Wy3, Wz3, Wc3, and Wd3are associated with activity counter504c, and constants C1, C2, C3, and C4are constants that may be added to the power approximation.

Depending on the instructions completed per cycle range, four different estimations with different weights and constant values are used for activity proxy architecture. For example, if control logic510determines that the instructions completed per cycle are less than or equal to a first predetermined value, then control logic510may send select signals to multiplexers514a-514dsuch that the power for activity counters504a,504b, and504cmay be approximated using the following model:
P=Wy1*A1+Wy2*A2+Wy3*A3+C1
If control logic510determines that the instructions completed per cycle are greater than the first predetermined value but less than or equal to a second predetermined value, then control logic510may send select signals to multiplexers514a-514dsuch that the power for activity counters504a,504b, and504cmay be approximated using the following model:
P=Wz1*A1+Wz2*A2+Wz3*A3+C2
If control logic510determines that the instructions completed per cycle are greater than the second predetermined value but less than or equal to a third predetermined value, then control logic510may send select signals to multiplexers514a-514dsuch that the power for activity counters504a,504b, and504cmay be approximated using the following model:
P=Wc1*A1+Wc2*A2+Wc3*A3+C3
Finally, if control logic510determines that the instructions completed per cycle are greater than the third predetermined value, then control logic510may send select signals to multiplexers514a-514dsuch that the power for activity counters504a,504b, and504cmay be approximated using the following model:
P=Wd1*A1+Wd2*A2+Wd3*A3+C4
WhileFIG. 5illustrates only four different instructions completed per cycle ranges, one of ordinary skill in the art will recognize that more or fewer instructions completed per cycle ranges may be used without departing from the spirit and scope of the invention.

WhileFIG. 5depicts that the plurality of predetermined weights and a plurality of predetermined constants are determined based on conditions within the data processing system, the illustrative embodiments recognize that one or more of the plurality of predetermined weights may be preset. Additionally, while preset weights and constants may be used and/or a plurality of predetermined weights and a plurality of predetermined constants may be selected based on instructions completed per cycle of the application that is being executed by a core, the illustrative embodiments are not limited to using only predetermined weights. That is, rather than using preset or predetermined weights and constants and control logic within the power proxies to determine which weight or constant should be selected, the illustrate embodiments may utilize power manager, such as power manager422to make decisions as to which weight should be used by each activity counter and which constants should be added to the chiplet activity approximation. Further, rather than the various power proxies performing computations to multiply the attribute counters with their associated weight and adding the results together along with a constant to approximate the power being used by the various activities being executed in a processor core, the illustrative embodiment recognize that these computations may be performed directly by a power manager, such as power manager422ofFIG. 4.

Thus, as described byFIG. 5, the aggregated activity estimate value, which is indicative of the power being used by each processor in executing activities of a workload, collected by power manager422may be, by returning toFIG. 4, retrieved by management control logic402and transferred to characterization and modeling logic404. For each processor, characterization and modeling logic404multiples the aggregated activity estimate value with a frequency scaling factor. Characterization and modeling logic404determines the frequency scaling factor by dividing a real-time measured frequency value by a specified fixed-frequency value. Again, the specified fixed-frequency value is a frequency value of a desired fixed-frequency mode specified by a user of data processing system400in order to determine a difference between the fixed-frequency mode and a current operating mode of data processing system400. By characterization and modeling logic404multiplying with the aggregated activity estimate value with the frequency scaling factor, characterization and modeling logic404obtains an frequency-scaled activity proxy counter value which is indicative of the activities being executed by the processors within data processing system400as a value of the specified fixed-frequency value.

Using vital processor data that is provided by the manufacturer and/or calculated at deployment time of data processing system400and stored in storage416, characterization and modeling logic404determines a slope of for the processor as shipped (slope_shipped) to be utilized as a power scaling factor. Characterization and modeling logic404obtains the slope_shipped value utilizing the following equation:
Slope_shipped=((VPD_pwr_noml_shipped−idle_proc_pwr_shipped(T))*slope_char)/(VPD_pwr_nom_char−idle_proc_pwr_char(T))
In this equation, idle_proc_pwr_char(T) value represents the idle power utilized by a processor under no workload prior to shipping. The idle_proc_pwr_char(T) value is a characteristic value for a processor within a same platform, for example, if the current processor is a processor in a blade server, then characterization and modeling logic404utilizes a idle_proc_pwr_char(T) value obtained from a vital product data (VPD) data structure in storage416for a processor characterized at the manufacturer as the idle_proc_pwr_char(T) value. The idle_proc_pwr_shipped(T) value represents the idle power utilized by the processor under no workload after shipping and, thus, is specific to the current device and processor.

Both the idle_proc_pwr_char(T) value and the idle_proc_pwr_shipped(T) value are obtained by management control logic402measuring idle power at different temperatures T, for example, for a range of 40° C. to 80° C. Management control logic402initially sets T to a low end of the range, i.e. 40° C. thereby forming Tthr1. Data processing system400then operates with no workload until the temperature associated with processors418stabilize to Tthr1. Once the temperature in data processing system400reaches Tthr1as monitored by one or more of thermal sensors410, management control logic402measures a first total processor power value P1via power sensors408. Management control logic402then sets T to a mid-point of the range, i.e. 60° C. thereby forming Tthr2. Data processing system400then operates with no workload until the temperature associated with processors418stabilize to Tthr2. Once the temperature in data processing system400reaches Tthr2as monitored by one or more of thermal sensors410, management control logic402measures a second total processor power value P2via power sensors408. Management control logic402then sets T to a high end of the range, i.e. 80° C. thereby forming Tthr3. Data processing system400then operates with no workload until the temperature associated with processors418stabilize to Tthr3. Once the temperature in data processing system400reaches Tthr3as monitored by one or more of thermal sensors410, management control logic402measures a third total processor power value P3via power sensors408.

Management control logic402then calculates a cool idle power slope value (idle_pwr_slope_cool) and a hot idle power slope value (idle_pwr_slope_hot) using the following equations:
idle_pwr_slope_cool=(P2−P1)/(Tthr2−Tthr1), and
idle_pwr_slope_hot=(P3−P2)/(Tthr3−Tthr2).
Thus, the cool idle power slope value (idle_pwr_slope_cool) and the hot idle power slope value (idle_pwr_slope_hot) may be, for example, ½ watt per degree Celsius, ⅜ watt per degree Celsius, ¼ watt per degree Celsius, or the like. Further, while the current example uses Celsius as the basis for temperature measurement, the illustrative embodiments are not limited to using only temperature measurements in Celsius. That is, any unit of measurement for temperature may be used, such as Fahrenheit, Kelvin, or the like.

Then, in order to obtain idle processor power values for all temperatures in the range of 40.1° C. to 59.9° C. and 60.1° C. to 79.9° C., management control logic402uses:the current total processor power value P2for the range of 40.1° C. to 59.9° C. and P3for the range of 60.1° C. to 79.9° C.,a highest temperature value Tcharwhich would be 60° C. for the range of 40.1° C. to 59.9° C. and 80° C. for the range of 60.1° C. to 79.9° C.,the desired temperature Tdes, andthe cool idle power slope value (idle_pwr_slope_cool) for the range of 40.1° C. to 59.9° C. and a hot idle power slope value (idle_pwr_slope_hot) for the range of 60.1° C. to 79.9° C.
Utilizing these values, management control logic402derives the idle processor power values utilizing the idle processor power (idle_proc_pwr(T)) model equation:

for 60.1° C. to 79.9° C.:
idle_proc_pwr(T)=P3+(Tdes−80° C.)*idle_pwr_slope_hot.
Once these calculations are completed for the desired temperature range, both at the manufacturer and in the field, management control logic402stores idle_proc_pwr_char(T) values and the idle_proc_pwr_shipped(T) values as separate data structures in storage416.

Returning to the slope_shipped equation, similar to the idle_proc_pwr_char(T) value that represents the idle power utilized by a processor under no workload prior to shipping, the nominal power characteristic of the processor prior to shipping is represented by the VPD_pwr_nom_char value. Also, similar to the idle_proc_pwr_shipped(T) value the represents the idle power utilized by the processor under no workload after shipping, the nominal power of the processor after shipment is represented by the VPD_pwr_noml_shipped value. Both the VPD_pwr_nom_char value and the VPD_pwr_noml_shipped value are determined by management control logic402initiating a constant and unvarying workload on processors418while keeping voltage and frequency levels steady. Management control logic402obtains a current total processor power value Pmeasfor processors418via power sensors408in order to establish a characteristic processor power value VPD_pwr_nom_char value while at the manufacturer and a VPD_pwr_noml_shipped value when initialized in the field. Similar to the idle_proc_pwr_char(T) value that represents the idle power utilized by a processor under no workload prior to shipping, the nominal power characteristic of the processor prior to shipping represented by the VPD_pwr_nom_char value may be for a similar processor within a same platform and not the actual processor.

The final component of the slope_shipped equation is the characteristic slope of the processor (slope_char). The slope_char value is obtained by management control logic402initiating a variety of workload on processors418while keeping voltage and frequency levels steady. For each workload, management control logic402obtains a current total processor power value Pmeasfor processors418via power sensors408as well as a aggregated activity estimate value Umeasfrom activity proxy logic406. After all the workload have been run, management control logic402obtains the slope_char value using the slope formula of:
slope_char=(Pmeas2−Pmeas1)/(Umeas2−Umeas1)
Once the slope_char value is obtained, management control logic402then calculates the slope_shipped value equation above and transfers this value to characterization and modeling logic404.

Characterization and modeling logic404multiplies the power scaling factor with the frequency-scaled activity proxy counter value to obtain a modeled active power value. Based on a current operating temperature of data processing system400obtained via management control logic402from thermal sensors410, characterization and modeling logic404identifies a shipped temperature dependent idle power value from a data structure of temperature dependent idle processor power values stored in storage416, derived as detailed above.

Characterization and modeling logic404adds the identified temperature dependent idle processor power value to the modeled active power value to obtain a modeled processor power value. In order to obtain a modeled total nominal power value for data processing system400during the current time interval, characterization and modeling logic404adds the modeled processor power value for each processor in data processing system400, a measured fan power value for the current time interval (described in detail below), as well as other measured power values associated with power consuming devices in data processing system400, such as memory device power, input/output (I/O) device power, service processor power, or the like.

With regard to the other measured power values associated with power consuming devices in data processing system400, management control logic402obtains these directly through power sensors408. These power values are normally fixed values or power values that do not vary significantly and, thus, may be considered constant once measured. With regard to the fan power value, management control logic obtains this value by management control logic402deriving the change in RPM as a function of temperature change ΔRPM/° C. by, under the constant workload on processors418, setting current thermal threshold value Tthr_cto a low end of a range of potential thermal threshold values Tthr, for example, for a range of 40° C. to 80° C., management control logic402would initially set Tthr_cto 40° C. thereby forming Tthr1. Data processing system400then processes the current workload until the temperature associated with processors418stabilizes. Once the temperature in data processing system400stabilizes, management control logic402measures a first fan speed in revolutions per minute RPM1via RPM sensors414. Management control logic402then sets current thermal threshold value Tthr_cto a high end of a range of potential thermal threshold values Tthr, for example, for a range of 40° C. to 80° C., management control logic402would set Tthr_cto 80° C. thereby forming Tthr2. Data processing system400then processes the current workload until the temperature associated with processors418stabilizes. Once the temperature in data processing system400stabilizes, management control logic402measures a second fan speed in revolutions per minute RPM2via RPM sensors414. Management control logic402then calculates the change in RPM as a function of temperature change ΔRPM/° C. value using the following change in RPM equation:
ΔRPM/° C.=(RPM2−RPM1)/(Tthr2−Tthr1)

With the obtained and derived characteristic information, management control logic402is then able to determine an optimal thermal threshold and fan power setting that minimizes system power without performance penalty and with fast convergence at runtime. That is, at runtime, management control logic retrieves a current thermal threshold value Tthr_cfrom a set of thermal thresholds in storage416that becomes the first thermal threshold under evaluation, a current total processor power value Pmeasfor processors418via power sensors408, a set of temperature values Tmeasread from thermal sensors410for processors418, and an ambient temperature value Tambfor data processing system400.

Management control logic402uses the current total processor power value Pmeas, a highest temperature value Tmaxfrom the set of temperature values Tmeas, the current thermal threshold value Tthr_c, and the Pleak_per_° C.scaling factor to calculate a total processor power value at the current thermal threshold value under consideration Pproc@Tthr_cusing the following total processor power model equation:
Pproc@Tthr_c=Pmeas+(Tthr_c−Tmax)*Pleak_per_° C.

With Pproc@Tthr_cdetermined, management control logic402determines a revolutions per minute value (RPM) required for a fan to reach the current thermal threshold value Tthr_c. Management control logic402uses the previously calculated total processor power value at the current thermal threshold value Pproc@Tthr_c, the current ambient temperature value Tambfor data processing system400, the current thermal threshold value Tthr_c, and the change in RPM as a function of temperature change ΔRPM/° C. value to determine an RPM value using the following RPM model equation:
RPM=((((Pproc@Tthr_c/Pproc_char)*(Tthr_char−Tamb_char))+Tamb)−Tthr_c)*ΔRPM/° C.+RPMchar.

Based on the determined RPM value for the fan, management control logic402identifies a fan power value Pfanusing a lookup table or, if a lookup table for the particular fan is not available, deriving its own fan power table. That is, normally, there are known wattage ratings associated with each fan speed based on the manufacturing model of the fan installed in data processing system400. Thus, management control logic402uses the determined RPM required for a fan to reach a desired temperature to identify in the lookup table what the fan power value Pfanwill be used at the determined RPM. However, in some instances lookup tables may not be available. Thus, management control logic402may derive a fan power model by initially setting the RPMs of a fan to a minimum rated RPM value for the fan and wait for the fan to reach the set RPM value. Once the fan reaches the set RPM value, management control logic402measures the power being consumed by the fan and stores the measured power value in a fan power table or other data structure. Management control logic402then increments the current RPM setting by an incremental value ΔRPM and determines whether the new RPM setting is greater than or equal to a maximum rated RPM value of the fan. If the new RPM setting is not greater than or equal to the maximum rated RPM value of the fan, then management control logic402sets the RPMs of a fan to the new RPM setting and waits for the fan to reach the set RPM value. Once the fan reaches the set RPM value, management control logic402again measures the power being consumed by the fan and stores the measure power value in the fan power table or other data structure, with the process repeating until the new RPM setting is greater than or equal to a maximum rated RPM value of the fan. If the incremental value is such that the fan power table does not comprise some power values for some RPM values, then management control logic402may use existing algorithms as a function of RPM to derive the unknown power values based upon other RPM and power values in the fan power table. Therefore, based on the determined RPM value for the fan, management control logic402may identify the fan power value Pfanfrom the derived fan power table.

By characterization and modeling logic404adding the modeled processor power value for each processor in data processing system400, the measured fan power value for the current time interval, as well as other measured power values associated with power consuming devices in data processing system400, characterization and modeling logic404obtains the modeled total nominal power value for data processing system400during the current time interval, which characterization and modeling logic304stores in storage316.

In order to provide a comparison of determined modeled total nominal power values in relation to the dynamic power management mode value, for each time interval, management control logic402determines a dynamic power management mode power value, which management control logic402also stores in storage416associated with the modeled processor power value of the same time interval. In order to determine dynamic power management mode power value, management control logic402implements logic in a final power model that provides a run-time fixed-frequency power estimation in the dynamic power saving mode.

For each subsequent time interval, characterization and modeling logic404again determines a new modeled total nominal power value and management control logic402determines a dynamic power management mode power value. During each subsequent operation, the temperature of data processing system400will rise and fall with the work being performed which not only effects the temperature dependent idle power value but all the fan power value as the fan speed will change with the temperature change. Thus, characterization and modeling logic404stores the modeled total nominal power value for the current interval in storage416and management control logic402stores the determined dynamic power management mode power value in storage416associated with the modeled processor power value of the same time interval.

Finally, once characterization and modeling logic404stores a plurality of modeled total nominal power values and management control logic402stores a plurality of dynamic power management mode power values for a specified time period, characterization and modeling logic404and/or management control logic404may provide a comparison of the plurality of modeled total nominal power values and the plurality of dynamic power management mode power values to the user such as through a graphical representation, a numerical representation, or the like.

FIG. 6is a flowchart illustrating an exemplary operation performed to obtain an aggregated activity estimate value within a processor in accordance with an illustrative embodiment. The operation ofFIG. 6may be implemented in a processor, such as processor318ofFIG. 3 or 418ofFIG. 4. As the operation begins, a power manager within the processor receives a set of activities to be monitored for one or more components of the processor and an activity proxy threshold value for each of the one or more components (step602). Activity proxy logic for each monitored component stores a value for each activity of the set of activities in an assigned counter of a set of counters, forming a set of stored values, wherein the value comprises the count will be multiplied by a weight factor specific to the activity (step604).

Prior to multiplying each of the stored values for each of the subset of activities to its associated weight factor, for each subset of activities, the power manager determines the weight factor that will be used. In this example, rather than using preset or predetermined weights and constants and control logic within the power proxies to determine which weight or constant should be selected, a decision as to which weight should be used by each activity counter and which constants should be added to the power approximation may be made by a power manager, such as power manager402ofFIG. 4. The weight factor and constant factor may be based on conditions related to the application being executed on the specific core to which the activity proxy logic is associated, such as instructions completed per cycle, number of threads in operation, voltage, temperature, voltage leakage, or the like. Based on the conditions related to the application being executed on the specific core, the power manager may identify the weight factor and constant factor to use (step606).

The activity proxy logic then multiplies the total value for each stored value by the identified weight factor that corresponds to the activity (step608). The activity proxy logic sums the stored values corresponding to each activity in the set of activities to form a total value for the set of activities (step610). While summing the stored values for the set of activities to form an aggregated activity estimate value, the activity proxy logic also adds to aggregated activity estimate value a constant factor identified by the power manager (step612). The activity proxy logic then sends the aggregated activity estimate value to a power manager within the processor (step614) and onto management control logic within the data processing system (step616), with the operation terminating thereafter.

FIG. 7depicts a flowchart outlining exemplary operations for deriving an idle processor power, either characterized or shipped, in accordance with an illustrative embodiment. As the operation begins, management control logic initiates a constant workload on a set of processors in a data processing system (step702). The management control logic sets a current thermal value T to a low end of a range (step704). For example, for a range of 40° C. to 80° C., the management control logic would initially set Tthr1to 40° C. The data processing system then processes the current workload until the temperature associated with the processors stabilizes (step706). The management control logic determines whether the temperature has stabilized by monitoring the ambient temperature of the data processing system via a thermal sensor (step708). If at step708the temperature of the data processing system has not stabilized, then the operation returns to step706. If at step708the temperature of the data processing system has stabilized, the management control logic measures a first total processor power value P1(step710).

The management control logic then sets the current thermal value T to a midpoint of the range (step712). For example, for a range of 40° C. to 80° C., the management control logic would set T to 80° C. thereby forming Tthr2. The data processing system then processes the current workload until the temperature associated with the processors stabilizes (step714). The management control unit determines whether the temperature has stabilized by monitoring the ambient temperature of the data processing system via a thermal sensor (step716). If at step716the temperature of the data processing system has not stabilized, then the operation returns to step714. If at step716the temperature of the data processing system has stabilized, the management control unit measures a second total processor power value P2(step718).

The management control logic then sets the current thermal value T to a high end of a range (step720). For example, for a range of 40° C. to 80° C., the management control logic would set T to 80° C. thereby forming Tthr3. The data processing system then processes the current workload until the temperature associated with the processors stabilizes (step722). The management control unit determines whether the temperature has stabilized by monitoring the ambient temperature of the data processing system via a thermal sensor (step724). If at step724the temperature of the data processing system has not stabilized, then the operation returns to step722. If at step724the temperature of the data processing system has stabilized, the management control unit measures a third total processor power value P3(step726). The management control unit then calculates a cool idle power slope value (idle_pwr_slope_cool) and a hot idle power slope value (idle_pwr_slope_hot) (step728) using the following equations:
idle_pwr_slope_cool=(P2−P1)/(Tthr2−Tthr1), and
idle_pwr_slope_hot=(P3−P2)/(Tthr3−Tthr2).
Thus, the cool idle power slope value (idle_pwr_slope_cool) and the hot idle power slope value (idle_pwr_slope_hot) may be, for example, ½ watt per degree Celsius, ⅜ watt per degree Celsius, ¼ watt per degree Celsius, or the like. Further, while the current example uses Celsius as the basis for temperature measurement, the illustrative embodiments are not limited to using only temperature measurements in Celsius. That is, any unit of measurement for temperature may be used, such as Fahrenheit, Kelvin, or the like.

The management control logic then derives the unknown idle processor power values (step730) utilizing the idle processor power (idle_proc_pwr(T)) model equation:

for temperatures between low temperature and midpoint temperature:
idle_proc_pwr(T)=P2+(Tdes−midpoint temperature)*idle_pwr_slope_cool

for temperatures between midpoint temperature and high temperature:
idle_proc_pwr(T)=P3+(Tdes−high temperature)*idle_pwr_slope_hot.
Once these calculations are completed for the desired temperature range, both at the manufacturer and in the field, the management control logic then stores idle processor power values as separate data structures in a storage (step732), with the operation ending thereafter.

FIG. 8depicts a flowchart outlining exemplary operations for deriving change in RPM as a function of temperature change ΔRPM/° C. in accordance with an illustrative embodiment. As the operation begins, management control logic initiates a constant workload on a set of processors in a data processing system (step802). The management control logic sets a current thermal threshold value Tthr_cfrom a store of thermal thresholds to a low end of a range of potential thermal threshold values Tthr_i(step804). For example, for a range of 40° C. to 80° C., the management control logic would initially set Tthr_cto 40° C. thereby forming Tthr1. The data processing system then processes the current workload until the temperature associated with the processors stabilizes (step806). The management control logic determines whether the temperature has stabilized by monitoring the ambient temperature of the data processing system via a thermal sensor (step808). If at step808the temperature of the data processing system has not stabilized, then the operation returns to step806. If at step808the temperature of the data processing system has stabilized, the management control logic measures a first fan speed in revolutions per minute RPM1via a set of RPM sensors (step810).

The management control logic then sets the current thermal threshold value Tthr_cto a high end of a range of potential thermal threshold values Tthr_i(step812). For example, for a range of 40° C. to 80° C., the management control logic would set Tthrto 80° C. thereby forming Tthr2. The data processing system then processes the current workload until the temperature associated with the processors stabilizes (step814). The management control logic determines whether the temperature has stabilized by monitoring the ambient temperature of the data processing system via a thermal sensor (step816). If at step816the temperature of the data processing system has not stabilized, then the operation returns to step814. If at step816the temperature of the data processing system has stabilized, the management control logic measures a second fan speed in revolutions per minute RPM2via the set of RPM sensors (step818). The management control logic then calculates the change in RPM as a function of temperature change ΔRPM/° C. value (step820) using the following change in RPM equation:
ΔRPM/° C.=(RPM2−RPM1)/(Tthr2−Tthr1)
After step820the operation ends.

FIG. 9depicts a flowchart outlining exemplary operations for deriving a fan power model in accordance with an illustrative embodiment. As the operation begins, the management control logic initially sets the revolutions per minute (RPMs) of a cooling fan to a minimum rated RPM value for the fan (step902). The management control logic then waits for the fan to reach the set RPM value (step904). The management control logic determines whether the RPMs of the fan have reached the set RPM value as measured via an RPM sensor (step906). If at step906the RPMs of the fan have not reached the RPM value, then the operation returns to step904. If at step906the RPMs of the fan have reached the set RPM value, then the management control logic measures the power being consumed by the fan (step908) and stores the measured power value in a fan power table or other data structure (step910). The management control logic then increments the current RPM setting by an incremental value ΔRPM (step912). The management control logic determines whether the new RPM setting is greater than or equal to a maximum rated RPM value of the fan (step914) If at step914the new RPM setting is not greater than or equal to the maximum rated RPM value of the fan, then the management control logic sets the RPMs of a fan to the new RPM setting (step916), with the operation returning to step904thereafter. If at step914the new RPM setting is greater than or equal to the maximum rated RPM value of the fan, the management control logic determines whether there are any RPM values in the fan power table or other structure that are missing (step918). If at step918there are any missing RPM values, the management control logic may use existing algorithms as a function of RPM to derive the unknown power values based upon other RPM and power values in the fan power table (step920), with the operation ending thereafter. If at step918, there are no missing RPM values, the operation ends.

FIG. 10depicts a flowchart outlining exemplary operations for fixed-frequency characterization and modeling to estimate energy/power consumption of a fixed-frequency operating mode while system is running in dynamic power management mode in accordance with an illustrative embodiment. As the operation begins, for each time interval within a time period, characterization and modeling logic identifies a real-time aggregated activity estimate value for each processor within a data processing system via management control logic and activity proxy logic that indicate the power being used by each processor in executing activities of a workload (step1002). For each processor, the characterization and modeling logic multiples the aggregated activity estimate value with a frequency scaling factor (step1004). By the characterization and modeling logic multiplying with the aggregated activity estimate value with the frequency scaling factor, the characterization and modeling logic obtains an frequency-scaled activity proxy counter value which is indicative of the activities being executed by the processors within the data processing system as a value of the specified fixed-frequency value (step1006).

Using vital processor data that is provided by the manufacturer and/or calculated at deployment time of the data processing system and stored in storage, the characterization and modeling logic determines a slope for the processor as shipped (slope_shipped) and utilizes this value as a power scaling factor (step1008). The characterization and modeling logic multiplies the power scaling factor with the frequency-scaled activity proxy counter value to obtain a modeled active power value (step1010). Based on a current operating temperature of the data processing system obtained via the management control logic from a set of temperature sensors, the characterization and modeling logic identifies a shipped temperature dependent idle power value from a data structure of temperature dependent idle processor power values stored in the storage (step1012).

The characterization and modeling logic adds the identified shipped temperature dependent idle processor power value to the modeled active power value to obtain a modeled processor power value (step1014). In order to obtain a modeled total nominal power value for the data processing system during the current time interval, the characterization and modeling logic adds the modeled processor power value for each processor in the data processing system, a measured fan power value for the current time interval, as well as other measured power values associated with power consuming devices in the data processing system, such as memory device power, input/output (I/O) device power, service processor power, or the like (step1016). The characterization and modeling logic stores the modeled total nominal power value for the current interval in the storage (step1018).

In order to provide a comparison of determined modeled total nominal power values in relation to the dynamic power management mode value, for each time interval within the time period, management control logic determines a dynamic power management mode power value (step1020). The management control logic stores the dynamic power management mode power value in the storage associated with the modeled processor power value of the same time interval (step1022). The characterization and modeling logic and the management control logic then determine whether the time period has expired (step1024). If at step1024the time period has not expired, then the operation returns to step1002and1020. If at step1024the time period has expired, then the characterization and modeling logic and/or the management control logic provides a comparison of the plurality of modeled total nominal power values and the plurality of dynamic power management mode power values (step1026), with the operation ending thereafter.

Thus, the illustrative embodiments provide mechanisms that enable customers to visualize their energy savings when running servers in a variable-frequency power-saving mode over a fixed-frequency nominal mode without actually running in the nominal mode. The mechanisms provide an accurate power modeling method based on power-correlated activity counters and one-time system characterizations of processor, fan and other server components.