Method for Autonomous Dynamic Voltage and Frequency Scaling of Microprocessors

BACKGROUND OF THE INVENTION

0001The present invention relates to the adaptive dynamic management of computer system operations, and more specifically to the dynamic voltage and frequency scaling (DVFS) of microprocessors.

0002Generally, microprocessor performance gain is achieved by increasing the microprocessor (clock) frequency. But this goes along with the requirement of a higher effort in production and development costs, finally resulting in higher asset costs for computer systems. Permanent rise of the nominal frequency goes along with high requirements on cooling techniques and materials. Many microprocessor manufacturers dimension the maximal microprocessor frequency rather conservative to ensure operational stability and make some worst-case assumptions, so that for example environmental setups like those provided in air-conditioned rooms for huge server clusters are feasible.

0003Power consumption and the associated heat generation of modern microprocessors are key design issues in the development process of computer systems, especially when the available space is very limited like in desktop systems or blade centers. Many mechanisms exist in contemporary microprocessors to vary its power consumption, e.g. by explicitly decreasing or increasing frequency and voltage. Many modern microprocessors provide such DVFS mechanisms. Enhanced SpeedStep is one of those and supported by various Intel microprocessors.

0004An important feature of contemporary microprocessors is the availability of a multitude of performance counters providing detailed information about workload characteristics, e.g. information about retired (completed) Instructions Per clock Cycle (IPC), processor cache misses, etc.

0005Nominal microprocessor frequencies used in computer systems are based on worst case assumptions concerning certain characteristics; e.g., ambient temperature and power demand of workloads. In general, the microprocessor hardware allows frequencies that are significantly higher than the nominal frequencies. Thermal limitations are frequently alleviated by modern cooling techniques or an air conditioned setting of the system. Microprocessor power consumption depends significantly on the type of workload. However, in typical customer scenarios, the worst case assumptions do not occur simultaneously.

0006Various approaches to autonomously reduce microprocessor power consumption exist when there has been no or little system utilization detected for some period of time. A metric often used for workload characterization is the IPC number. It allows characterizing the microprocessor performance independent of its clock frequency. A method for prediction of workload phase duration and characterization is proposed in C. Isci et al “Long-Term Workload Phases: Duration Predictions and Applications to DVFS”, IEEE Micro, Vol. 25, 5/2005, pp. 39-51. That work mainly concentrates on a workload estimation using a last-value prediction. A gradient-based workload prediction technique based on linear regression is described in W. L. Bircher et al “Runtime Identification of Microprocessor Energy Saving Opportunities”, Proc. of the ILSPED 2005, pp. 275-280.

0007The so-called Foxton technology as used in the Intel Itanium2 is an example for a mechanism used in contemporary microprocessors to increase frequency and voltage above the default values by using a temporary overdlocking on the chip level. Descriptions of the Foxton technology are given in R. McGowen et al “Power and temperature control on a 90-nm Itanium family processor” IEEE Journal of Solid State Signals Vol. 1, 1/2006, pp. 229-237 and T. Fischer et al “A 90-nm variable frequency clock system for a power-managed itanium architecture processor”, IEEE Journal of Solid State Signals Vol. 1, 1/2006, pp. 218-228.

0008Existing DVFS solutions mainly focus on the improvement of microprocessor energy efficiency and not boosting of its performance. They optimize microprocessor power consumption with only minimal impact on the performance of the workload currently executed by the microprocessor.

SUMMARY OF THE INVENTION

0009It is therefore an object of the present invention to provide a method for autonomous DVFS of a microprocessor that is improved over the prior art, and a corresponding computer program and computer program product, and a corresponding computer system.

0010The advantages of the present invention are achieved by the autonomous detecting of phases of high microprocessor workload and prediction of their duration. The microprocessor frequency will be temporarily increased to an appropriate safe value (even beyond nominal frequency) consistent with technological and ambient constraints in order to improve performance when the computer system comprising the microprocessor benefits most, while during phases of low microprocessor workload its frequency and voltage will be decreased to save energy. This technique exploits hidden performance capabilities and improves the total performance of a computer system without compromising operational stability. No additional hardware such as service processors is needed for contemporary computer systems supporting performance counters and DFVS already.

0011A method in accordance with the invention basically consists of steps for measurement, prediction and control in conjunction with a computer system comprising at least one microprocessor. More detailed, the method comprises the steps of: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0012">collecting and storing performance data of said computer system during a period of time;</li><li id="ul0002-0002" num="0013">predicting future workload metrics and their duration for said computer system from the stored performance data, and classifying the current workload for said computer system at least in phases of normal and high workload based on the predicted future workload metrics and their predicted duration;</li><li id="ul0002-0003" num="0014">modifying parameters of said computer system suitable to increase the frequency and voltage of said microprocessor for current workloads classified as a phase of high workload;</li><li id="ul0002-0004" num="0015">modifying frequency and voltage of said microprocessor to their normal values for current workloads classified as a phase of normal workload</li></ul></li></ul>

0016In the preferred embodiment of the invention the following steps are iterated at a specified sampling interval, recording data to obtain previously calculated values: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0017">calculating the power consumption P of the computer system comprising the microprocessor during the most recent sampling interval (t_n−1, t_n), dividing the difference of the total aggregated energy values at time t_n and t_n−1 by the sampling interval duration;</li><li id="ul0004-0002" num="0018">measuring the microprocessor temperature;</li><li id="ul0004-0003" num="0019">calculating the current IPC of the microprocessor by using its performance counters;</li><li id="ul0004-0004" num="0020">predicting microprocessor workload phase characteristics based on the current IPC;</li><li id="ul0004-0005" num="0021">checking whether a prediction for the current IPC exists;</li><li id="ul0004-0006" num="0022">if a prediction exists, keeping the predicted value and previous workload classifications, otherwise checking whether a prediction should be performed by applying an appropriate stability criteria;</li><li id="ul0004-0007" num="0023">if no new prediction should be performed, invalidating all predicted values, classifying the workload as normal, otherwise checking whether a prediction for the previous sampling time from a previous prediction exists;</li><li id="ul0004-0008" num="0024">if a prediction for the previous sampling time exists, checking whether the prediction for the previous sampling time deviates less than a specified value from the current IPC and if not, invalidating all predicted values and classifying the current workload as normal;</li><li id="ul0004-0009" num="0025">if no prediction for the previous sampling time exists, determining whether enough previously measured samples have been collected for a prediction, and if not, keeping the predicted values and previous workload classification, otherwise performing a prediction for the duration of the current workload phase, predicting the IPC for the current workload phase, and classifying the predicted workload in idle, normal, and high workloads;</li><li id="ul0004-0010" num="0026">if the predicted workload is idle, setting the microprocessor frequency and voltage to the minimum allowed values;</li><li id="ul0004-0011" num="0027">if the predicted workload is normal, setting the microprocessor frequency and voltage to their nominal values;</li><li id="ul0004-0012" num="0028">if the predicted workload is high, activating a control feedback loop circuit to set the microprocessor frequency and voltage autonomously according to power or temperature setpoints in order to prevent hardware damages or malfunctions.</li></ul></li></ul>

0029The invention allows significantly increasing the total computer system performance with only minimal impact on power consumption.

BRIEF DESCRIPTION OF THE DRAWINGS

0030The present invention and its advantages are now described in conjunction with the accompanying drawings.

0031<figref idref="DRAWINGS">FIG. 1</figref>: Is block diagram illustrating the system architecture of an embodiment of the invention;

0032<figref idref="DRAWINGS">FIG. 2</figref>: Is a graph of a function illustrating gradient-based workload duration prediction according to the invention;

0033<figref idref="DRAWINGS">FIG. 3</figref>: Is a graph of a workload phase duration prediction over time;

0034<figref idref="DRAWINGS">FIG. 4</figref>: Is a block diagram of a microprocessor power control loop according to the invention;

0035<figref idref="DRAWINGS">FIG. 5</figref>: Is a block diagram of a microprocessor temperature control loop according to the invention;

0036<figref idref="DRAWINGS">FIG. 6</figref>: Is a block diagram of a flow chart for a method in accordance with the invention;

0037<figref idref="DRAWINGS">FIG. 7</figref>: Is a block diagram of a flow chart for a method in accordance with the invention;

0038<figref idref="DRAWINGS">FIG. 8</figref>: Is a block diagram of a flow chart for a method in accordance with the invention;

0039<figref idref="DRAWINGS">FIG. 9</figref>: Is a block diagram of a system in which certain embodiments may be implemented.

DETAILED DESCRIPTION

0040TurboMode

0041<figref idref="DRAWINGS">FIG. 1</figref> illustrates the system architecture of an embodiment of the invention in a computer system <b>100</b>. The embodiment is called TurboMode. A Xeon microprocessor is used as CPU (Central Processing Unit) <b>110</b> in the computer system <b>100</b>. The Xeon microprocessor can control its operation by using a set of MSRs (Model Specific Registers) <b>120</b>. A system management processor <b>130</b> controls the operation of the computer system <b>100</b>. It uses a set of hardware sensors <b>140</b> to monitor the hardware elements of the computer system <b>100</b> including the CPU <b>110</b>. The computer system <b>100</b> executes an instance of the Linux operating system with a Linux kernel <b>150</b> instance and various processes running in the user-level <b>160</b> of the Linux operating system.

0042The Linux kernel <b>150</b> comprises various kernel modules that can especially create kernel threads that are running concurrently. The invention uses the AME (Autonomic Management of Energy) <b>170</b> kernel module and the timer facility <b>180</b> of the Linux kernel <b>150</b>. The timer <b>150</b> facility allows using Linux kernel timers—data structures that instruct the Linux kernel <b>150</b> to execute a user-defined function with a user-defined argument at a user-defined time. This function runs then asynchronously to the process that registered the timer. Typical resolutions for the Linux system timer <b>180</b> facility allow a maximal sampling frequency of 1 kHz for measurements.

0043A TurboMode kernel module <b>190</b> implements a method in accordance with the present invention. An optional TurboMode monitoring process <b>200</b> in the user level <b>160</b> allows to present information about the current operational state of TurboMode to users of the computer system <b>100</b>. The TurboMode monitoring process <b>200</b> provides also a tracing facility to keep a logbook about the Turbomode operational state. The interface to the tracing facility is realized via entries in the Linux proc filesystem. The AME <b>170</b> kernel module provides interfaces for sensor data measurements, which are used by the TurboMode kernel module <b>190</b> to read sensor data from the sensors <b>140</b>. The timer facility <b>180</b> periodically calls the TurboMode kernel module <b>190</b> to sample sensor data for the sensor <b>140</b>, for which it uses a separate kernel thread.

0044A potential implementation for the computer system <b>100</b> is described in the IBM Research Report RC23835 (W0512-086), Dec. 19, 2005: X. Wang et al “Managing Peak System-level Power with Feedback Control”. An IBM BladeCenter comprises multiple HS20 blades with Intel Xeon processors. The power management is shown there in <figref idref="DRAWINGS">FIG. 1</figref> BladeCenter Chassis. Two different Xeon microprocessors were used: The Intel Xeon Nocona and the Intel xeon Irwindale. Both microprocessors have a nominal frequency of 3.6 GHz.

0045The system management processor <b>130</b> is implemented by the Hitachi H8S 2166 service processor. The AME <b>170</b> accesses the sensors <b>140</b> via I/O (input/output) ports from the system management processor <b>130</b>, which are made accessible for reading by the TurboMode kernel module <b>190</b>. This allows a fast access to sensor data, which is required for high sampling frequencies and results in better operating stability and higher granularity for dynamic changes. A sampling interval of 10 ms for the sensor data turned out to be sufficient for this environment for the sampling kernel thread of the TurboMode kernel module <b>190</b>.

0046Workload Prediction

0047<figref idref="DRAWINGS">FIG. 2</figref> illustrates the gradient-based prediction of IPC values as used for the workload phase duration prediction according to the present invention. Previously measured IPC values (IPC(t_<b>0</b>), IPC(t_<b>1</b>)) are used to calculate the gradient for the previous duration interval (t_<b>1</b>−t_<b>0</b>). This gradient is applied to predict the IPC values for the next duration interval (t<b>2</b>−t<b>1</b>). A prediction for a future IPC(t_<b>2</b>) is then calculated as follows:

0000<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mrow><mrow><mi>IPC</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mn>2</mn></mrow><mo>)</mo></mrow></mrow><mo>=</mo><mrow><mrow><mi>IPC</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>+</mo><mrow><mfrac><mrow><mrow><mi>IPC</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><mi>IPC</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mn>0</mn></mrow><mo>)</mo></mrow></mrow></mrow><mrow><mrow><mi>t_</mi><mo></mo><mn>0</mn></mrow><mo>-</mo><mrow><mi>t_</mi><mo></mo><mn>0</mn></mrow></mrow></mfrac><mo>·</mo><mrow><mo>(</mo><mrow><mrow><mi>t_</mi><mo></mo><mn>2</mn></mrow><mo>-</mo><mrow><mi>t_</mi><mo></mo><mn>1</mn></mrow></mrow><mo>)</mo></mrow></mrow></mrow></mrow></math></maths>

0048The basic rationale for predicting the duration is that if a specific number of consecutive measured IPC values lies within a specified window, the IPC can be declared as stable, which means that it follows a constant progression. So if this number of stable samples is seen, the assumption can be made that a particular amount of further samples lying in the stability window will be seen. With an increasing number of consecutive stable samples, the predicted number of following samples also rises.

0049A number of consecutive stable samples (X₀) are required to perform a first prediction, where stability is defined by the criterion that each sample has to lie within a predefined threshold to each other. It is assumed that if X_nsamples are seen (X₀on first iteration), X_n+1further samples within the stability criterion will follow. This process is iterated until the maximal allowed prediction duration is reached or a single sample falls out of the stability criterion. In the first case, the predicted duration is kept at its previous value (X_n+1=X_n) in the second one it is reset to X₀. This algorithm can be described as follows:

0000<maths id="MATH-US-00002" num="00002"><math overflow="scroll"><mrow><mrow><msub><mi>X</mi><mrow><mi>n</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>=</mo><mrow><msub><mi>X</mi><mi>n</mi></msub><mo>+</mo><mfrac><msub><mi>X</mi><mi>n</mi></msub><mi>S</mi></mfrac></mrow></mrow><mo>;</mo><mrow><msub><mi>X</mi><mn>0</mn></msub><mo>=</mo><mi>S</mi></mrow></mrow></math></maths>

0050Measurements based on Standard Performance Evaluation Corporation (SPEC) CPU 2000 benchmark results have shown that good results can be achieved with S:=8. In this case the algorithm starts with an initial number of 8 subsequent stable samples, which are required to do a first prediction. Then, a prediction is made that nine further stable samples will be seen. If during these nine samples no sample fails out of the stability window, the next prediction will be performed, estimating that another ten samples will match the stability criterion This process will be iterated until a single sample will fall out the window and deviates more than specified by the limit from the measured IPC. An example phase duration prediction graph using this algorithm is shown in <figref idref="DRAWINGS">FIG. 2</figref>.

0051Measurements for a TurboMode implementation in an IBM BlaceCenter computer system similar to the one described earlier have shown that samples fall out of the window occasionally due to IPC measurement failures caused by timing problems or noises on the IPC induced by running background processes in the user-level <b>160</b> and kernel threads in the Linux kernel <b>150</b> of the Linux operating system. Timing problems even led to short but huge outliers that corrupt gradient calculation. Because the Linux kernel running on the IBM HS20 blades in the IBM BladeCenter had no hard real-time support, this problem may not be eliminated. Therefore, the median value of the current IPCs is calculated as well as their average. The median is the 50-percentile of a data series. It can be determined by sorting the series by value and picking the one from the middle. The advantage of the median value lies in its capability to filter even huge outliers.

0052To get the median value of the actual workload, the values for following IPCs would be required. This is impossible and estimated results would even lead to a bigger process error. So on calculation the median of the IPC M/2 samples ago is received as illustrated in the following equation for M=3:

0000<maths id="MATH-US-00003" num="00003"><math overflow="scroll"><mrow><mrow><mi>MED</mi><mo></mo><mrow><mo>(</mo><mrow><mi>ipc</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mrow><mo>(</mo><mrow><mi>now</mi><mo>-</mo><mrow><mi>M</mi><mo>/</mo><mn>2</mn></mrow></mrow><mo>)</mo></mrow></mrow><mo>)</mo></mrow></mrow><mo>)</mo></mrow></mrow><mo>=</mo><mrow><mi>MED</mi><mo></mo><mrow><mo>{</mo><mrow><mrow><mi>ipc</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mrow><mo>(</mo><mrow><mi>now</mi><mo>-</mo><mi>M</mi></mrow><mo>)</mo></mrow></mrow><mo>)</mo></mrow></mrow><mo>;</mo><mrow><mi>ipc</mi><mo></mo><mrow><mo>(</mo><mrow><mi>t_</mi><mo></mo><mrow><mo>(</mo><mrow><mi>now</mi><mo>-</mo><mrow><mi>M</mi><mo>/</mo><mn>2</mn></mrow></mrow><mo>)</mo></mrow></mrow><mo>)</mo></mrow></mrow><mo>;</mo><mrow><mi>ipc</mi><mo></mo><mrow><mo>(</mo><mi>t_now</mi><mo>)</mo></mrow></mrow></mrow><mo>}</mo></mrow></mrow></mrow></math></maths>

0053A similar problem occurs at the average calculation, but this can be directly influenced as the new measured value is not filtered. This leads then to the problem that also outliers are not filtered in such a good way like they are with the median. M/2 sample intervals (t_Y-t_X) are needed for the median to recognize that a jump of the measured IPC occurred, whereas the average instantly reacts but suffers on the slow replacement of the old values in its buffer. This leads to an immoderate smoothing of the measurements and can cause overshoots in gradient calculation. Therefore, the number of samples used for gradient calculation should be greater than the amount of samples taken in the period of median phase shift (t_y-t_x). In order to get a compromise, both values will be used for the improvement of the measured IPC. The median values are used for gradient calculation, while the average values are utilized to calculate the deviation between the predicted and the measured IPC.

0054Power and Temperature Control

0055The TurboMode kernel module <b>190</b> implements a DVFS method in accordance with the present invention. Frequency and voltage of a microprocessor cannot be set independently and only to discrete values. A P-State (performance state) model defines available frequencies and voltages for a microprocessor in a lookup table to have discrete values for a fixed amount of states. In order to modify current operating frequency and voltage of the microprocessor, it can be transferred to a different P-State. For microprocessors supporting DVFS a bigger granularity of P-State definitions can be used in order to improve power control quality.

0056Microprocessor power consumption has to be controlled during high IPC phases to guarantee operational safety of the computer system and not to damage hardware. During phases of low or normal microprocessor workloads, power consumption should be as small as possible. Therefore, microprocessor frequency and voltage are set to their defaults values during phases of normal IPC, and even scaled down for phases of low IPC in order to save energy. Only during phases when the TurboMode kernel module <b>190</b> triggers a frequency boost, a power control loop must ensure that the power consumption stays within its limits.

0057According to the invention, either temperature or power will be controlled by a control feedback loop. <figref idref="DRAWINGS">FIG. 4</figref> illustrates schematically the functionality for such a power control loop <b>400</b>. As the setpoint for the control the maximal permanent power value P_MAXis used. The error e for the difference between P_MAXand P_ACTUALis used as the input for a PID controller to calculate the output depending on the specified parameters of the PID controller. The result is a value Δfv²that describes how much the product of the frequency and the squared voltage should be changed from its current value. With a lookup table LUT this value is transformed into a discrete frequency f and voltage v pair as the new settings for the microprocessor. The valve of the control loop <b>400</b> is the lookup table LUT that maps the output of the PID controller to discrete absolute frequency f and voltage v values that are fed into the microprocessor and will result into a new actual power P_ACTUALconsisting of a dynamic part P and a constant static part P_STATIC. This new power value P_ACTUALwill be measured at the start of the next sampling interval defined by a value Δt.

0058<figref idref="DRAWINGS">FIG. 5</figref> illustrates schematically the functionality of a temperature control loop <b>500</b> in accordance with the invention. The control loop <b>500</b> uses the PFi), the LUT and the sampling interval of the power control loop <b>400</b>. As the setpoint for the control the maximal permanent temperature value V_MAXis used. The error e for the difference between V_MAXand V_ACTUALis used as the input for the PID controller to calculate the output depending on the specified parameters of the PID controller The result is a value fv²that describes the product of the frequency and the squared voltage. With the lookup table LUT this value is transformed into a discrete frequency f and voltage v pair. The valve of the control loop <b>500</b> is the lookup table LUT that maps the output of the PID controller to discrete absolute frequency f and voltage v values that are fed into the microprocessor and will result into a new actual temperature V_ACTUALdepending on the current environmental temperature V_RNV. This new temperature value V_ACTUALwill be measured at the start of the next sampling interval defined by the value Δt.

0059In the preferred embodiment of the present invention, the PID controller is implemented by the TurboMode kernel module <b>190</b> with the help of the AME <b>170</b> kernel module and the MSRs <b>120</b> of the Xeon microprocessor. The PID controller separates current status of the computer system <b>100</b> basically between three different states for the CPU <b>110</b>: idle, normal, and high IPC phases. An indication for an idle phase is determined by the calculation of an activity factor of the CPU <b>110</b> describing its utilization. The activity factor is the number of clock cycles where the CPU <b>110</b> is not halted divided by the number of all clock cycles during a sampling interval. If the activity factor drops below a specific threshold, the CPU <b>110</b> will be set by the TurboMode kernel module <b>190</b> to the P-State used for the idle phase. In this case, the microprocessor frequency and voltage of the CPU <b>110</b> are set to the lowest possible P-State in order to save energy. For the detection and treatment of idle phases also well-known methods to reduce microprocessor power consumption can be used.

0060During normal IPC phases, microprocessor frequency and voltage are set to their default P-State in order to allow standard operational behaviour of the CPU <b>110</b>. Microprocessor power and temperature control is not active during idle or normal IPC phases as power and temperature limits for the microprocessor cannot be reached. During phases with high IPC, the TurboMode kernel module <b>190</b> sets microprocessor frequency and voltage of the CPU <b>110</b> to a P-State that allows a performance boost for the CPU <b>110</b>. For this P-State the power and control loop needs to ensure that power and temperature limits are not exceeded in order to prevent hardware damages and malfunctions.

0061The invention can be extended to multiple CPUs in the computer system <b>100</b>. In that case, a separate power and temperature control loop can be used for every CPU or the same power and temperature control loop can be used for all CPUs.

0062Measurement and Prediction

0063A Linux kernel timer is configured to execute a specific function of the TurboMode kernel module <b>190</b>. This function triggers a sleeping sampling kernel thread to perform measurement and prediction and configuring the Linux kernel timer for the next triggering after same interval of time (sampling interval). This way a periodic rescheduling process of the sampling kernel thread is achieved. This rescheduling process is continued until a specified number of samples have been collected. Then a tracing thread created by the TurboMode kernel module <b>190</b> is triggered to write the collected measurement and prediction data into a trace tile.

0064<figref idref="DRAWINGS">FIG. 6</figref> shows the general control flow for the sampling kernel thread. In step <b>600</b> it is determined if the sampling thread was triggered by the Linux kernel timer. If not, the sampling kernel thread is sleeping in step <b>610</b> until it will be triggered by the Linux kernel timer. If the sampling kernel thread was triggered (step <b>600</b>), sensor data is read from the AME <b>170</b> kernel module in step <b>620</b>. The collected sensor data is then used in step <b>630</b> together with the content of the MSRs <b>120</b> to predict the IPC. In step <b>640</b> it will be determined if the tracing thread needs to be triggered in case tracing is enabled. In step <b>650</b> it will be checked if the sampling kernel thread needs to be cancelled in case the Linux kernel <b>150</b> has sent a kill signal to the sampling kernel thread If no kill signal was received, then the Linux kernel timer will be set up to trigger execution of the sampling thread after the sampling time has elapsed.

0065Reading sensor data via the AME <b>170</b> kernel module is a measurement for the entire computer system <b>100</b> and therefore does not depend on the number of CPUs (in case there are more CPUs than the single CPU <b>110</b>). In the very first sampling of sensor data no prediction will be performed. <figref idref="DRAWINGS">FIG. 7</figref> provides a more detailed control flow for the collection of the sensor data for the following iterations. In step <b>700</b> it will be tested, if the AME recording bit provided by the AME <b>170</b> kernel module is set. If so, no new sensor data is provided by the AME <b>170</b> kernel module and the old values will be kept in step <b>710</b>. Otherwise the I/O ports provided by the AME <b>170</b> kernel module are read in step <b>720</b>. In step <b>730</b> it is determined if power and temperature relevant sensor data has not changed. If so, then the old values will be kept in step <b>740</b>. Otherwise it will be checked in step <b>750</b> if the number of new sensor data is equal to the time difference between the current and the last sampling. If not, then in step <b>760</b> the sensor data from the previous sampling time will be used instead of the sensor data from the current sampling time. Finally, in step <b>770</b> the new power and temperature values will be calculated.

0066For example, the power related sensor data can be the energy consumption of the CPU <b>110</b>. Then the new power value is calculated by dividing the difference of the energy consumption by the time interval. In order to improve performance, the measurement can be performed separately and concurrently on each CPU.

0067The control flow for the Xeon microprocessor performance counter measurement and the IPC prediction is shown in <figref idref="DRAWINGS">FIG. 8</figref>. As with the reading of the sensor data, the very first step is omitted as only the performance counter values can be collected. On the subsequent iterations the calculation of basic metrics like IPC, frequency and processor cache misses per cycle (CMPC) is performed after the collection of the performance counter values. In step <b>800</b> the performance counter values are collected from the MSRs <b>120</b>. The metrics are calculated in step <b>810</b>. The median value and the average of the IPC are calculated in step <b>820</b>.

0068In step <b>830</b> it will be checked if the number of samples to he collected until the next prediction has to be performed is equal 0. If so, then the old prediction values will be kept in step <b>890</b>. Otherwise stability criteria for the CPU <b>110</b> will be tested in step <b>840</b>. These stability criteria are defined as follows: The current median value of the IPC must not deviate from the previous value by more than a predefined value, and the current IPC value must not deviate from the previous value by more than a predefined value.

0069In step <b>850</b> it will be checked if stability criteria for the IPC are fulfilled. If not, then the predicted values are reset in step <b>891</b>. Otherwise it will be checked in step <b>860</b> if a prediction of the IPC was performed earlier. If so, then this prediction will be tested in step <b>870</b> for a maximal tolerance interval. This tolerance interval is given by the absolute difference to the current average of the IPC. If the previous prediction is not within the maximal tolerance interval, then it will be reset in step <b>891</b>. Otherwise it will be used for the prediction in step <b>892</b>. If no previous prediction of the IPC was detected in step <b>860</b>, then it will be checked in step <b>880</b> if enough samples are available for a prediction. If so, then they will be used for the prediction in step <b>892</b>. Otherwise further samples will be collected in step <b>893</b>.

0070After prediction is done (subsequent to the steps <b>891</b>, <b>892</b>, <b>893</b>) it will be determined in step <b>894</b> if the computer system <b>100</b> would benefit from a performance boost for the CPU <b>110</b>. This is performed by checking whether the current predicted IPC and its duration exceeds a specified threshold. If so, a frequency boost for the CPU <b>110</b> will be initiated. On a currently running frequency boost, it will be tested, if the IPC has dropped down below a lower threshold for an amount of specified samples to stop the frequency boost. If a frequency boost can be applied, a flag will be set to indicate this to the control loop.

0071Another embodiment for the invention could be an implementation as part of a Hypervisor, which is a scheme allowing multiple operating systems to run, unmodified, on a computer system at the same time. Also performance counters can be provided by other facilities such as Hypervisors or workload managers.

0072Additional Embodiment Details

0073The described techniques may be implemented as a method, apparatus or article of manufacture involving software, firmware, micro-code, hardware and/or any combination thereof. The term “article of manufacture” as used herein refers to code or logic implemented in a medium, where such medium may comprise hardware logic [e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.] or a computer readable medium, such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices [e.g., Electrically Erasable Programmable Read Only Memory (EEPROM), Read Only Memory (ROM), Programmable Read Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, firmware, programmable logic, etc.]. Code in the computer readable medium is accessed and executed by a processor. The medium in which the code or logic is encoded may also comprise transmission signals propagating through space or a transmission media, such as an optical fiber, copper wire, etc. The transmission signal in which the code or logic is encoded may further comprise a wireless signal, satellite transmission, radio waves, infrared signals, Bluetooth, etc. The transmission signal in which the code or logic is encoded is capable of being transmitted by a transmitting station and received by a receiving station, where the code or logic encoded in the transmission signal may be decoded and stored in hardware or a computer readable medium at the receiving and transmitting stations or devices. Additionally, the “article of manufacture” may comprise a combination of hardware and software components in which the code is embodied, processed, and executed. Of course, those skilled in the art will recognize that many modifications may be made without departing from the scope of embodiments, and that the article of manufacture may comprise any information bearing medium. For example, the article of manufacture comprises a storage medium having stored therein instructions that when executed by a machine results in operations being performed.

0074Certain embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

0075Furthermore, certain embodiments can take the form of a computer program product accessible from a computer usable or computer readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAN), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.

0076The terms “certain embodiments”, “an embodiment”, “embodiment”, “embodiments”, “the embodiment”, “the embodiments”, “one or more embodiments”, “some embodiments”, and “one embodiment” mean one or more (but not all) embodiments unless expressly specified otherwise. The terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless expressly specified otherwise. The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a”, “an” and “the” mean “one or more”, unless expressly specified otherwise.

0077Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries. Additionally, a description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments.

0078Further, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously, in parallel, or concurrently.

0079When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments need not include the device itself.

0080<figref idref="DRAWINGS">FIG. 9</figref> illustrates a block diagram of a computer system <b>900</b> in which certain embodiments may be implemented. The system <b>900</b> may include a circuitry <b>902</b> that may in certain embodiments include a microprocessor <b>904</b>. The computer system <b>900</b> may also include a memory <b>906</b> (e.g., a volatile memory device), and storage <b>908</b>. The storage <b>908</b> may include a non-volatile memory device (e.g., EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, firmware, programmable logic, etc.), magnetic disk drive, optical disk drive, tape drive, etc. The storage <b>908</b> may comprise an internal storage device, an attached storage device and/or a network accessible storage device. The system <b>900</b> may include a program logic <b>910</b> including code <b>912</b> that may be loaded into the memory <b>906</b> and executed by the microprocessor <b>904</b> or circuitry <b>902</b>. In certain embodiments, the program logic <b>910</b> including code <b>912</b> may be stored in the storage <b>908</b>. In certain other embodiments, the program logic <b>910</b> may be implemented in the circuitry <b>902</b>. Therefore, while <figref idref="DRAWINGS">FIG. 9</figref> shows the program logic <b>910</b> separately from the other elements, the program logic <b>910</b> may be implemented in the memory <b>906</b> and/or the circuitry <b>902</b>.

0081Certain embodiments may be directed to a method for deploying computing instruction by a person or automated processing integrating computer-readable code into a computing system, wherein the code in combination with the computing system is enabled to perform the operations of the described embodiments.

0082At least certain of the operations illustrated in the figures may be performed in parallel as well as sequentially. In alternative embodiments, certain of the operations may be performed in a different order, modified or removed.

0083Furthermore, many of the software and hardware components have been described in separate modules for purposes of illustration. Such components may be integrated into a fewer number of components or divided into a larger number of components. Additionally, certain operations described as performed by a specific component may be performed by other components.

0084The data structures and components shown or referred to in the figures and the description are described as having specific types of information. In alternative embodiments, the data structures and components may be structured differently and have fewer, more or different fields or different functions than those shown or referred to in the figures.

0085Therefore, the foregoing description of the embodiments has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Many modifications and variations are possible in light of the above teaching.