WO2025004124A1 - Uncore frequency control device, uncore frequency control method, and uncore frequency control program - Google Patents

Abstract

An Uncore frequency control device (1) comprises: a monitoring unit (110) that collects HW operation status data from a compute (2) for a prescribed period; an analysis unit that employs data counted up over time as metrics to be analyzed, categorizes the metrics into a metrics A group in which a metrics value progressively increases as a load amount applied to an application increases, a metrics B group in which the metrics value decreases at a timing when degradation in application performance occurs, or a metrics C group in which the metrics value converges at a timing when degradation in application performance occurs, and determines metrics to be monitored; and a frequency control unit (140) that sets the Uncore frequency to the minimum value when the metrics B and C are not below the normalized value of the metrics A.

Description

Uncore frequency control device, Uncore frequency control method, and Uncore frequency control program

The present invention relates to an uncore frequency control device, an uncore frequency control method, and an uncore frequency control program.

In server operation and management, the issue of power consumption has become important, and power-saving technologies have been investigated. For example, DVFS (Dynamic Voltage and Frequency Scaling) and virtualization technology can be used to improve resource utilization. DVFS is a technology that controls the voltage and frequency of CPU cores.

On the other hand, in recent years, CPUs have been released that allow different operating frequencies to be set for the core and non-core parts (uncore) within the CPU package. The core part consists of the CPU core and L1 and L2 caches. The uncore part consists of the LLC (Last Level Cache), memory controller, system bus, etc.

　It is generally said that CPU power consumption is proportional to the product of the square of the voltage and the frequency, and power consumption can be reduced by lowering the voltage and frequency. However, lowering the frequency and voltage leads to a degradation of processing performance. Therefore, in order to minimize the impact of performance degradation depending on the load, technology has been proposed that dynamically lowers the frequency and voltage depending on the load on the CPU.

The basic concept of frequency control in this case will be explained.
(1) Reducing the CPU core frequency leads to a decrease in the performance of the calculation processing in the core. Based on this, existing research adopts the following frequency increase/decrease methods.
"CPU-intensive processing" → "Increase the core frequency"
"Memory-intensive processing" → "Lower the core frequency"
(2) Reducing the CPU uncore frequency affects the cache line transfer speed and memory bandwidth. Based on this, existing research adopts the following frequency increase/decrease methods:
"CPU-intensive processing" → "Lower the uncore frequency"
"Memory-intensive processing" → "Increase the Uncore frequency"

Intel (registered trademark, hereafter the same) has introduced a function called UFS (Uncore Frequency Scaling) for the CPU that can set the operating frequency separately for the Core and Uncore. This UFS function allows the processor to dynamically change the Uncore frequency according to the load, and can achieve the same power saving effect as DVFS for the CPU core (see Non-Patent Document 1).
On the other hand, Linux (registered trademark, the same applies below) employs a technology that allows the minimum and maximum scaling frequencies to be set via sysfs.

Moreover, in research on Uncore's operating frequency control, a control method targeted at HPC (High-Performance Computing) has been proposed (see Non-Patent Document 2).
In Non-Patent Document 2, App (Application) performance is analyzed by changing the uncore frequency from measurements using benchmarks with multiple processing characteristics. As a result, it is difficult for UFS to perform optimal frequency control for all Apps, and control according to the characteristics of the App and user requirements is necessary, and a unique uncore frequency control method is proposed.

Srinivas Pandruvada, “Intel Uncore Frequency Scaling,” Intel Corporation, 2022, [online], [Retrieved June 1, 2020], Internet <URL: https://www.kernel.org/doc/html/latest /admin-guide/pm/intel_uncore_frequency_scaling.html Andre, Etienne, et al., “DUF: Dynamic Uncore Frequency scaling to reduce power consumption.” Concurrency and Computation: Practice and Experience 34.3 (2022): e6580.

However, the applications targeted in existing research such as Non-Patent Document 2 are numerical calculation programs used in natural science research, and no control method has been proposed for the uncore operating frequency in service systems such as web servers.
Numerical calculation programs and Web applications differ in that they use batch processing and real-time processing, and this difference is also reflected in the evaluation criteria for the two. In batch processing, performance is evaluated by the time it takes to complete processing, and power is evaluated by the amount of power consumed until the processing is completed. On the other hand, in real-time processing, performance is evaluated by response time and throughput, and power is evaluated by power consumption.

In this real-time processing, performance also differs depending on the load, such as the number of requests the server processes. For example, when the frequency value is fixed, the performance (response time) differs depending on the load (number of requests) even in simple HTTP request processing that returns an HTML file. Therefore, for applications that perform real-time processing, such as web services and network services, it is necessary to control the frequency according to fluctuations in the load.

Furthermore, when performing real-time processing, the performance requirements for a Web service application are, for example, a response time of 100 ms, which is not as strict as that of a NW service. If the optimal frequency according to the method described in Non-Patent Document 2 is applied to such a Web service application, a state occurs in which there is still room for power reduction during low load. For example, as shown in FIG. 8, during low load, there is a margin before the response time violates the SLA. Therefore, even if the frequency is further reduced, it is possible to reduce the power consumption within a range that does not violate the SLA.
In other words, in Web service applications that do not have strict performance requirements, it is expected that the power reduction effect will be further increased in low load areas (problem 1).

In addition, there are other issues to be addressed when controlling server frequencies:
(Challenge 2)
When monitoring some kind of indicator obtained from the server and controlling the frequency in stages according to the amount of fluctuation indicated by that indicator, if frequency changes occur frequently due to sudden fluctuations in the load, overhead will be generated due to CPU interrupt control, leading to degradation of application performance.
Therefore, it is necessary to suppress the effect of overhead caused by frequency change processing.

(Challenge 3)
The contents of some applications are a black box to server administrators, and server administrators may not be able to obtain values that are directly related to the application's performance requirements (e.g., response time) or the amount of load on the server (e.g., number of requests).
Therefore, a method is required to determine when performance degradation due to an increase in load will occur, simply by monitoring information obtained from the HW (server, etc.) on which the application is installed. In addition, the method must be able to handle various load fluctuations, such as fluctuations due to date and time and fluctuations due to noise.

The present invention was made in consideration of these points, and aims to improve the power reduction effect in low-load areas in systems equipped with web-based applications.

The uncore frequency control device of the present invention is an uncore frequency control device that controls the uncore frequency of a physical server that is a compute equipped with a web service application, and includes a monitoring unit that collects data including HW operation status data from the compute for a predetermined period of time, and of the collected data, data that is counted up over time is used as a metric to be analyzed. The metrics are normalized using a Min-Max method and then classified into a metric A group whose metric values increase as the load on the web service application increases, a metric B group whose metric values decrease when the load increases and application performance deteriorates, and a metric C group whose metric values converge when the load increases and application performance deteriorates, and at least one of the metric B group and the metric C group is selected. The system is characterized by comprising an analysis unit that selects one metric B and/or metric C, selects one metric A from the group of metrics A that has a smaller normalized value than the selected metric B and/or metric C during low load before the application performance degradation occurs, and determines the selected metric as the monitoring target; a metrics acquisition unit that acquires data on metric A and metric B and/or metric C to be monitored from the compute and performs normalization using the Min-Max method; and a frequency control unit that sets the uncore frequency of the compute to a configurable maximum value if either the normalized value of metric B or metric C is lower than the normalized value of metric A, and sets the uncore frequency of the compute to a configurable minimum value if the normalized value is not lower.

The present invention makes it possible to improve the power reduction effect in low-load areas in systems equipped with web-based applications.

1 is a diagram showing an overall configuration of an Uncore frequency control system including an Uncore frequency control device according to an embodiment of the present invention. 13 is a graph showing normalized values for the loadings of metrics A, B, and C. 11 is a diagram illustrating the relationship between an increase in load and deterioration of App performance. 1 is a diagram showing the trends of Metrics A and Metrics B over a given period of time in the past. 10 is a flowchart showing a flow of a metrics determination process performed by the uncore frequency control device according to the present embodiment before uncore frequency control. 11 is a flowchart showing a process flow in which an uncore frequency device according to the present embodiment performs uncore frequency control using determined metrics. FIG. 2 is a hardware configuration diagram showing an example of a computer that realizes the functions of the Uncore frequency control device according to the present embodiment. FIG. 13 is a diagram for explaining a state in which a margin for power reduction remains during low load in the prior art.

Next, we will explain the form for implementing the present invention (hereinafter referred to as the "present embodiment").

The Uncore frequency control device according to this embodiment collects various data from a server on which a Web service application is installed, and among that data, determines which data will be used as an index for control. This index data is data that is counted up over time ("metrics" described below). The Uncore frequency control device checks the trend of the rate of increase of each metric relative to the load, and determines which metrics to monitor. The Uncore frequency control device then divides the load into low and high load regions depending on the point in time when the rate of increase of the metric changes, and performs frequency control that prioritizes performance guarantees in the high load region and power consumption reduction in the low load region (details described below).

FIG. 1 is a diagram showing the overall configuration of an uncore frequency control system 1000 including an uncore frequency control device 1 according to this embodiment.
As shown in FIG. 1, an uncore frequency control device 1 is communicatively connected to each compute (physical server) 2 that is to be the subject of uncore frequency control.

Each compute 2 has an application (App) 200 (here, a Web service application) implemented on HW (hardware). Note that this application 200 may be implemented in a VM (Virtual Machine) or a container. Each compute 2 also has data collection software 21 and an IPMI (Intelligent Platform Management Interface) 22.

The data collection software 21 is software that collects performance data of the Compute 2, and acquires App performance values and HW operation status data. Note that App performance values are, for example, response time and throughput, but depending on the specifications of the application, there are cases where this App performance value cannot be acquired. Therefore, the data collection software 21 according to this embodiment acquires at least HW operation status data.
The HW operation status data is an index that is a reference for the load of the Compute 2, and is performance data that can be acquired from each Compute 2, such as CPU usage, cache misses, and the number of received packets, or performance values obtained from the logs of the Apps running on the Compute 2. From this HW operation status data, data (metrics) that are indexes for determining the control of the Uncore frequency described below are determined (details will be described later).
The data collection software 21 may be existing data collection software such as Perf and dstat, or may be a self-created software.

IPMI 22 is a standard interface for monitoring and managing the state of hardware, and includes a power consumption measurement means. IPMI 22 implements application (App) 200 to measure the power consumption of Compute 2 when a load is applied. Note that this power consumption measurement means is not limited to IPMI 22, and if Compute 2 includes a power meter, the power consumption may be measured by the power meter.

Compute 2 transmits data indicating the HW operation status when a load is applied to the implemented application 200 and information on power consumption to the Uncore frequency control device 1. Then, Compute 2 obtains the setting information of the Uncore frequency from the Uncore frequency control device 1 and sets the optimal Uncore frequency according to the load.

≪Uncore Frequency Control Device≫
Next, the uncore frequency control device 1 and the like according to this embodiment will be described.
The uncore frequency control device 1 classifies data that can be acquired only by the compute 2 on which the application 200 is installed into those whose values increase relative to the amount of load (metrics A group described below), those whose values decrease when App performance deteriorates (metrics B group described below), and those whose values converge when App performance deteriorates (metrics C group described below). Then, it determines the metrics to be monitored from each of metrics A, B, and C. If metrics B and C determined from metrics B and C are larger than metric A determined from metrics A, the uncore frequency control device 1 sets the uncore frequency to the minimum value that can be set, and if they are smaller, sets the uncore frequency to the maximum value that can be set.
This enables power reduction, especially in low load regions, in the server (Compute 2) that provides the Web service application, and also enables frequency control based on information from the server (HW) even when necessary information (performance information) cannot be obtained from the Web service application. In addition, by simplifying control based on load fluctuations, it is possible to reduce the overhead of control processing compared to existing methods.
As shown in FIG. 1, the uncore frequency control device 1 includes a control unit 10, an input/output unit 11, and a storage unit 12.

The input/output unit 11 inputs and outputs information between each compute 2, etc. This input/output unit 11 is composed of a communication interface that transmits and receives information via a communication line, and an input/output interface that inputs and outputs information between an input device such as a keyboard and an output device such as a monitor, which are not shown in the figure.

The storage unit 12 is composed of a hard disk, a flash memory, a RAM (Random Access Memory), or the like.
In this storage unit 12, a data store 100 is stored.

The data store 100 stores HW operation status data and power consumption that are collected from each compute 2 by the monitoring unit 110 described below. The data store 100 also stores information such as normalized values of metrics that are acquired by the metrics acquisition unit 130 via the monitoring unit 110 and that are determined to be monitored by the analysis unit 120 described below.

The control unit 10 is responsible for all the processing performed by the Uncore frequency control device 1, and is composed of a monitoring unit 110, an analysis unit 120, a metrics acquisition unit 130, and a frequency control unit 140.

The monitoring unit 110 collects data (HW operation status data) from a server (Compute 2) on which a Web service application is installed.
For this data collection, existing data collection software such as Perf and dstat, or self-created software can be used. Also, if you are using Linux, you can use, for example, Linux perf stat as a data collection tool.

The analysis unit 120 analyzes the data collected by the monitoring unit 110, determines the index to be used for controlling the uncore frequency, and determines the logic to be used in the control algorithm based on the analysis results.

The determination of the index used for uncore frequency control by the analysis unit 120 will be described.
The analysis unit 120 analyzes data that is counted up over time among the data collected by the monitoring unit 110. This data is called "metrics." These metrics are counter values that indicate the state of the server (Compute 2) provided by HW, SW, etc., such as the number of instruction executions, context switches, and cache misses.

When there is no load or a low to medium load, processing is smooth and the metrics increase. However, if the request queue becomes clogged for some reason, the increase in metrics changes. The analysis unit 120 identifies the monitoring targets required to detect when such a bottleneck occurs as metrics.

The analysis unit 120 checks the trend of the rate of increase in relation to the load for the multiple metrics collected by the monitoring unit 110, and classifies them into the following three groups. At this time, the analysis unit 120 performs normalization using the Min-Max method, since the absolute values of each value are different.

2 is a graph showing normalized values versus load for metrics A, B, and C. The metrics are classified into three groups based on their increasing trends.
Metrics Group A: The metric value increases as the load increases.
Metrics group B: The metric values decrease when the load increases and app performance deteriorates.
Metrics group C: The metric values converge when the load increases and App performance degradation occurs.

The analysis unit 120 determines one metric (metric A) to be monitored from the classified metrics group A. The analysis unit 120 also determines at least one of metrics B and metrics C to be monitored from the metrics groups B and C. Note that one metric may be selected from the metrics group B and one from the metrics group C to be monitored.
Here, with regard to metric A selected from metric A group, the analysis unit 120 selects one that has a smaller value under low load than metrics B and C, as shown in FIG.
The analysis unit 120 then stores the Min/Max values used for normalization during the analysis in the data store 100 .

Furthermore, in this embodiment, as shown in Figure 3, the load on the server (Compute 2) is defined as being in the low load region or the high load region based on the point in time when degradation of App performance occurs and the value of metric B decreases or the value of metric C converges (dashed line x in Figures 2 and 3).

The analysis unit 120 determines metrics A, B, and C as indices to be used for controlling the uncore frequency based on the analysis result, and then determines logic to be used in a control algorithm for controlling the uncore frequency.
The metrics to be used as indices may be metric A and metric B, metric A and metric C, or metric A, metric B, and metric C.

As a pre-processing of data to be handled by the logic used in the control algorithm, the analysis unit 120 first collects the determined metrics (for example, metrics A, B, and C) at a predetermined time interval and normalizes them.
Then, the following logic is used to compare the size of the metrics:
The normalized values are compared to determine whether "metric B or C > metric A." Here, it is determined whether either metric B or metric C is greater than metric A. In other words, it is determined whether the load amount shown in Figures 2 and 3 is in the low load area. If "metric B or C > metric A," the logic is set to set the uncore frequency to the minimum value that can be set.
Meanwhile, the normalized values are compared to determine whether "metric B or C < metric A." Here, it is determined whether either metric B or metric C is smaller than metric A. In other words, it is determined whether the load amount shown in Figures 2 and 3 is in the high load area. If "metric B or C < metric A," the logic is set to set the uncore frequency to the maximum value that can be set.

Furthermore, the analysis unit 120 employs the following logic to determine whether or not to proceed to a comparison of the magnitude of the metrics.
[1] Determining whether or not there is a load If the value of any of metrics A, B, or C (normalized using the Min-Max method) is greater than or equal to a predetermined threshold (e.g., 0.1), proceed to a control decision (comparing the size of the metrics).
This logic is provided to prevent unnecessary processing when there is no load or an extremely low load.

[2] Judgment based on metric noise In the monitoring unit 110, metrics B and C collected at a specified time interval may become noisy during a transition period from low load to high load. In the following explanation, metric B is used, but the same applies to metric C.

4 is a diagram showing the trends of metrics A and B over a given period of time in the past. As shown in FIG. 4, during the transitional period from a low load region to a high load region, the magnitude relationship between metrics A and B changes many times due to noise. Therefore, when the difference between the maximum and minimum values of metric B is equal to or less than a given percentage of the total size (a given first percentage: for example, 20%), a comparison of the magnitude with metric A is performed. In other words, when the difference between the maximum and minimum values of metric B exceeds a given percentage of the total (for example, 20%), a comparison of the magnitude is not performed.
This makes it possible to prevent frequent changes to the uncore frequency setting due to noise, thereby preventing processing overhead.

Alternatively, when transitioning from high load to low load, if noise is detected (i.e., the difference between the maximum and minimum values is equal to or greater than a predetermined percentage of the total size (predetermined second percentage: for example, 10%)), a control hysteresis is provided and a magnitude comparison (control decision) is made between "metric B+b" and "metric A-a." Note that a (second predetermined value) and b (first predetermined value) are any real numbers with 0<a, b<1. By setting the control hysteresis in this way, even if metric B fluctuates near the threshold, frequent switching due to the influence of that control can be avoided.

The frequency control unit 140, described below, controls the uncore frequency using a control algorithm based on these logics determined by the analysis unit 120.

Returning to FIG. 1, the metrics acquisition unit 130 acquires information on the metrics that are the indices determined by the analysis unit 120 from the server (Compute 2) via the monitoring unit 110. The metrics acquisition unit 130 then normalizes the acquired metrics A, B, and C using the Min-Max method and stores them in the data store 100.

The frequency control unit 140 executes uncore frequency control using metrics A, B, and C, which are indicators acquired by the metrics acquisition unit 130 via the monitoring unit 110, according to a control algorithm based on the logic generated by the analysis unit 120. Details of the process executed by the frequency control unit 140 (control algorithm) will be described later with reference to the flowchart in FIG. 6.

Processing the Uncore Frequency Control Device
Next, the process executed by the Uncore frequency control device 1 will be described.
Fig. 5 is a diagram showing a flow of a metrics determination process performed by the uncore frequency control device 1 prior to (in advance of) uncore frequency control. Fig. 6 is a diagram showing a flow of a process performed by the uncore frequency control device 1 using the determined metrics to perform uncore frequency control.

First, the flow of the metrics determination process in FIG. 5 will be described.
The monitoring unit 110 (FIG. 1) of the Uncoore frequency control device 1 collects data (HW operation status data) for a predetermined period of time from a server (Compute 2) on which a Web service application is installed (step S10).

Next, the analysis unit 120 of the Uncoore frequency control device 1 performs normalization using the Min-Max method on the data acquired by the monitoring unit 110 that is counted up over time (for example, counter values indicating the server state such as the number of instructions executed, context switches, cache misses, etc.) (step S11).
The Min/Max values used in this normalization are stored in the data store 100.

Then, the analysis unit 120 checks the trend of the increase rate against the load amount, and classifies the metrics into three groups: "metrics group A" whose metric values increase as the load amount increases, "metrics group B" whose metric values decrease when the load amount increases and app performance degradation occurs, and "metrics group C" whose metric values converge when the load amount increases and app performance degradation occurs (step S12).

Then, one type from metric group A and at least one type from metric group B and metric group C are determined as indexes to be used for controlling the uncore frequency (step S13).
Alternatively, one type from metric group A, one type each from metric group B and C may be determined as the index to be used for controlling the uncore frequency.
Furthermore, if there are multiple candidates in each metric group, any metric can be selected, but for metric A selected from metric group A, the metric with a smaller value at low load than metrics B and C selected from metric groups B and C is selected (see Figure 2).

Next, the analysis unit 120 determines the logic to be used in the control algorithm (step S14).
Specifically, the analysis unit 120 determines logic for comparing the magnitude of the metrics according to the metrics that serve as the indices determined in step S13.
For example, in step S13, if metric A selected from metric group A and metric B selected from metric group B are determined as the indicators, the following logic is determined.
During control, normalized values are compared, and if "metric B>metric A", the uncore frequency is set to the minimum value that can be set.
During control, normalized values are compared, and if "metric B < metric A", the uncore frequency is set to the maximum value that can be set.
The same applies when metric C is determined as the index.

Also, for example, if in step S13, metric A selected from metric group A, metric B selected from metric group B, and metric C selected from metric group C are determined as the indicators, the following logic is determined.
During control, normalized values are compared, and if either metric B or metric C > metric A, the uncore frequency is set to the minimum value that can be set.
During control, normalized values are compared, and if either metric B or metric C is smaller than metric A, the uncore frequency is set to the maximum value that can be set.

[Logic for determining whether or not a load is applied]
Furthermore, the analysis unit 120 determines logic for determining whether or not a load is being applied to the metrics A, B, and C selected as indices in order to determine whether or not to perform a process for comparing the magnitude of the metrics.
The logic is determined as follows: if the value of any of metrics A, B, or C (normalized using the Min-Max method) is greater than or equal to a predetermined threshold (e.g., 0.1), then proceed to a control decision (comparison of the metrics).
It should be noted that this predetermined threshold value is, for example, determined in advance by a system administrator or the like, and is stored in the storage unit 12 of the uncore frequency control device 1 .

[Judgments based on metrics noise]
Furthermore, the analysis unit 120 determines whether the metrics are in a transitional period where the load is changing from low to high, and in this case, since the noise is large, determines logic for not comparing the magnitude of the metrics.
Specifically, for metrics B and C selected as metrics, the logic is determined such that the data on trends over a specified period of time in the past (e.g., 5 seconds) stored in the data store 100 is referenced, and if the difference between the maximum and minimum values is less than a specified percentage of the overall size (a specified first percentage: e.g., 20%), then control decision is made (a comparison of the size with metric A).

The analysis unit 120 also refers to the data of the past transitions for any period of time (e.g., 5 seconds) stored in the data store 100 for metrics B and C selected as the metrics, and determines the logic that, in the case of a transition from high load to low load, the maximum and minimum values exceed a predetermined percentage of the total (a predetermined second percentage: e.g., 10%), a control hysteresis is provided and a control decision (a comparison with metric A) is made as "metric B+b", "metric C+c", and "metric A-a". Here, a (second predetermined value), b (first predetermined value), and c (first predetermined value) are any real numbers in the range 0<a, b, c<1. Note that the first predetermined values b and c may be the same value or different values.

As a result, the Uncore frequency control device 1 can prevent frequent setting changes caused by noise, preventing processing overhead.

The frequency control unit 140 of the uncore frequency control device 1 controls the uncore frequency using a control algorithm based on the logic determined by the analysis unit 120 .
Next, the process flow (control algorithm) of the uncore frequency control will be described.

FIG. 6 is a diagram showing a process flow in which the uncore frequency control device 1 performs uncore frequency control using the determined metrics.
In this embodiment, it is assumed that the analysis unit 120 has determined that the indexes used to control the uncore frequency are metric A and metric B. It is also assumed that the analysis unit 120 has determined the logic for comparing the magnitude of the metrics, and that a predetermined threshold for determining whether a load is applied and a predetermined ratio (a predetermined first ratio, a predetermined second ratio) for making a judgment based on noise are preset.

First, the metrics acquisition unit 130 of the uncore frequency control device 1 acquires information on the metrics (here, metrics A and metrics B) that are the indicators determined by the analysis unit 120 from the server (Compute 2) via the monitoring unit 110 (step S20).
For example, the metrics acquisition unit 130 acquires data at one-second intervals via the monitoring unit 110 using a data collection tool (Linux per stat).
Then, for the acquired metrics A and B, the metrics acquisition unit 130 uses the Min/Max values used for normalization during analysis that were stored in the data store 100 , and stores the normalized values in the data store 100 .

Next, the frequency control unit 140 of the uncore frequency control device judges whether the metric value (metric A or metric B value) is equal to or greater than a predetermined threshold value (e.g., 0.1) (step S21). This process is for preventing unnecessary processing when there is no load or a very low load.
If the frequency is not equal to or greater than the predetermined threshold (step S21→No), that is, if there is no load or a very low load, the uncore frequency is not controlled and the process proceeds to step S28. On the other hand, if the frequency is equal to or greater than the predetermined threshold (step S21→Yes), the process proceeds to the next step S22.

In step S22, the frequency control unit 140 determines whether the difference between the maximum and minimum values of the data of metric B (normalized value) collected during a specified time period in the past (e.g., 5 seconds) is less than a specified percentage of the total (a specified first percentage: e.g., 20%).
If the difference between the maximum and minimum values is not equal to or less than a predetermined ratio (a first predetermined ratio) of the total (step S22→No), the influence of noise is deemed large, and the uncore frequency is not controlled, and the process proceeds to step S28. On the other hand, if the difference is equal to or less than the predetermined ratio (a first predetermined ratio) (step S22→Yes), the process proceeds to the next step S23.

In step S23, the frequency control unit 140 determines whether the Uncore frequency currently set in Compute 2 is the maximum value and whether the difference between the maximum and minimum values of the data of metric B (normalized value) collected during a specified time in the past (e.g., 5 seconds) is greater than or equal to a specified percentage of the total (a specified second percentage: e.g., 10%).
Here, if the Uncore frequency currently set in Compute 2 is the maximum value, it means that the current load is high and that the load is transitioning from high to low, and if the difference between the maximum and minimum values is greater than a predetermined percentage of the total (a predetermined second percentage: for example, 10%), it means that the influence of noise is relatively large.
If the requirement of step S23 is not met (step S23→No), the process proceeds to step S25. On the other hand, if the requirement of step S23 is met (step S23→Yes), the process proceeds to step S24.

In step S24, the frequency control unit 140 sets a control hysteresis.
Specifically, frequency control unit 140 sets the value of metric B to "metric B+b" and the value of metric A to "metric A-a," where a and b are any real numbers such that 0<a, b<1. Then, the process proceeds to step S25.

In step S25, the frequency control unit 140 determines whether the value of metric B is lower than the value of metric A (metric B<metric A).
If the value of metric B is not lower than the value of metric A (step S25→No), the frequency control unit 140 sets the uncore frequency to the minimum value that can be set (step S26). If the current value is the minimum value, the current state is maintained. Then, the process proceeds to step S28.
On the other hand, if the value of metric B is lower than the value of metric A (step S25→Yes), the uncore frequency is set to the maximum value that can be set (step S27). If the current value is the maximum value, the current state is maintained. Then, the process proceeds to step S28.

In step S28, the frequency control unit 140 determines whether or not the Web service has ended in the compute 2. If the Web service has not ended (step S28→No), the frequency control unit 140 returns to step S20 and repeats the process.
On the other hand, if the Web service has ended (step S28→Yes), the entire process of the Uncore frequency control ends.

<Hardware Configuration>
The uncore frequency control device 1 according to this embodiment is realized by a computer 900 having a configuration as shown in FIG.
7 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the uncore frequency control device 1 according to this embodiment. The computer 900 includes a CPU 901, a ROM (Read Only Memory) 902, a RAM 903, a HDD (Hard Disk Drive) 904, an input/output I/F (Interface) 905, a communication I/F 906, and a media I/F 907.

The CPU 901 operates based on a program (uncore frequency control program) stored in the ROM 902 or HDD 904, and is controlled by the control unit 10 (Fig. 1). The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, programs related to the hardware of the computer 900, etc.

The CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display or printer, via an input/output I/F 905. The CPU 901 acquires data from the input device 910 via the input/output I/F 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

The HDD 904 stores the programs executed by the CPU 901 and the data used by the programs. The communication I/F 906 receives data from other devices via a communication network (e.g., NW (Network) 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

The media I/F 907 reads the program (uncore frequency control program) or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads the program related to the target processing from the recording medium 912 onto the RAM 903 via the media I/F 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a semiconductor memory, etc.

For example, when the computer 900 functions as the uncore frequency control device 1 of the present invention, the CPU 901 of the computer 900 executes a program loaded onto the RAM 903 to realize the functions of the uncore frequency control program. In addition, the data in the RAM 903 is stored in the HDD 904. The CPU 901 reads and executes a program related to the target processing from the recording medium 912. In addition, the CPU 901 may read a program related to the target processing from another device via a communication network (NW 920).

＜Effects＞
The effects of the uncore frequency control device and the like according to the present invention will be described below.
The uncore frequency control device according to the present invention is an uncore frequency control device 1 that controls the uncore frequency of a physical server that is a compute 2 equipped with a web service application, and includes a monitoring unit 110 that collects data including HW operation status data from the compute 2 for a predetermined period of time, and among the collected data, data that is counted up over time is used as a metric to be analyzed. After normalizing the metrics using a Min-Max method, the metrics are classified into a metric A group whose metric values increase as the load on the web service application increases, a metric B group whose metric values decrease when the load increases and application performance deteriorates, and a metric C group whose metric values converge when the load increases and application performance deteriorates, and at least one of the metric B group and the metric C group is selected. the analysis unit 120 selecting one metric A having a smaller normalized value than the selected metric B and/or metric C from the group of metrics A during a low load period before application performance degradation occurs and determining the selected metric as the monitoring target; a metrics acquisition unit 130 acquiring data on metric A and metric B and/or metric C to be monitored from compute 2 and normalizing the data by a Min-Max method; and a frequency control unit 140 setting the uncore frequency of compute 2 to a settable maximum value if either one of the normalized values of metric B or metric C is lower than the normalized value of metric A, and setting the uncore frequency of compute 2 to a settable minimum value if the normalized value is not lower.

In this way, the uncore frequency control device 1 can increase the power reduction effect in a low load region in a system equipped with Web-based applications.
In addition, the uncore frequency control device 1 can change the uncore frequency from a settable minimum value to a settable maximum value when the compute state transitions from a low load region to a high load region that may violate the performance requirements. In this way, by simplifying the control of the uncore frequency due to load fluctuations, it is possible to reduce overhead due to frequency setting changes compared to conventional techniques.
Furthermore, even if the Uncore frequency control device 1 cannot obtain a value (e.g., response time) directly related to a performance requirement from an application installed in the Compute 2, the Uncore frequency control device 1 can determine the timing at which performance degradation occurs due to an increase in the load on the application, using the HW operation status data obtained from the Compute 2. Therefore, it is possible to reliably determine the timing of transition to a high load region and change the setting of the Uncore frequency.

Furthermore, in the uncore frequency control device 1, the frequency control unit 140 is characterized in that if any one of the values of each metric to be monitored, acquired and normalized by the metrics acquisition unit 130, is not equal to or greater than a predetermined threshold, the frequency control unit 140 does not perform the uncore frequency setting process for the compute 2.

By doing this, the Uncore frequency control device 1 does not perform the process of determining whether or not to change the uncore frequency setting when the load on the Compute 2 is zero or an extremely low load close to zero. Therefore, the Uncore frequency control device 1 can reduce the wasted power associated with unnecessary determination processes.

Furthermore, in the uncore frequency control device 1, the frequency control unit 140 is characterized in that it does not perform the process of setting the compute uncore frequency when the difference between the maximum and minimum values of metric B or metric C acquired and normalized by the metrics acquisition unit 130 at a specified time exceeds a specified first percentage of the total size of the normalized metrics.

By doing this, the uncore frequency control device 1 can avoid changing the uncore frequency setting when noise is large during the transition period from low load to high load in the collected metrics B or metric C. This allows the uncore frequency control device 1 to suppress an increase in uncore frequency setting changes due to noise, and reduce the overhead of the compute 2.

Furthermore, in the uncore frequency control device 1, when the uncore frequency of Compute 2 is currently set to the maximum value that can be set, and the difference between the maximum and minimum values of metric B or metric C acquired and normalized by the metrics acquisition unit 130 at a predetermined time is equal to or greater than a predetermined second percentage of the overall normalized size of the metrics, the frequency control unit 140 sets a control hysteresis by adding a first predetermined value to the normalized value of metric B and/or metric C determined to be the monitoring target, and subtracting a second predetermined value from the normalized value of metric A determined to be the monitoring target.

In this way, the Uncore frequency control device 1 can prevent frequent changes to the Uncore frequency setting by setting the control hysteresis. This allows the Uncore frequency control device 1 to reduce the overhead of the Compute 2.

The present invention is not limited to the embodiments described above, and many modifications are possible within the technical concept of the present invention by those with ordinary skill in the art.

1 Uncore frequency control device 2 Compute (physical server)
10 Control unit 11 Input/output unit 12 Storage unit 21 Data collection software 22 IPMI
100 Data store 110 Monitoring unit 120 Analysis unit 130 Metrics acquisition unit 140 Frequency control unit 200 Application (App)
1000 Uncore Frequency Control System

Claims (6)

An uncore frequency control device that controls an uncore frequency of a physical server that is a compute equipped with a Web service application,
A monitoring unit that collects data including HW operation status data from the compute for a predetermined period of time;
an analysis unit which uses data that is counted up over time from among the collected data as metrics to be analyzed, normalizes the metrics using a Min-Max method, and then classifies the metrics into a metric A group whose metric values increase as the load on the Web service application increases, a metric B group whose metric values decrease when the load increases and application performance degradation occurs, and a metric C group whose metric values converge when the load increases and application performance degradation occurs, and selects at least one metric B and/or metric C from the metric B group and the metric C group, and selects one metric A from the metric A group whose normalized value is smaller than that of the selected metric B and/or metric C during a low load period before the application performance degradation occurs, and determines the selected metric to be monitored;
a metrics acquisition unit that acquires data of metrics A, metrics B and/or metrics C to be monitored from the compute and performs normalization using the Min-Max method;
a frequency control unit that sets the uncore frequency of the compute to a configurable maximum value when either the normalized value of the metric B or the normalized value of the metric C is lower than the normalized value of the metric A, and sets the uncore frequency of the compute to a configurable minimum value when either the normalized value of the metric B or the normalized value of the metric C is not lower than the normalized value of the metric A;
An Uncore frequency control device comprising: The frequency control unit is
The uncore frequency control device according to claim 1, characterized in that if any one of the values of each metric of the monitored object acquired and normalized by the metrics acquisition unit is not greater than a predetermined threshold, the uncore frequency setting process of the compute is not performed. The frequency control unit is
The uncore frequency control device of claim 1, characterized in that when the difference between the maximum and minimum values of metric B or metric C acquired and normalized by the metrics acquisition unit at a specified time exceeds a specified first percentage of the total normalized size of the metrics, the uncore frequency setting process of the compute is not performed. The frequency control unit is
The uncore frequency control device of claim 1, characterized in that when the uncore frequency of the compute is currently set to the maximum value that can be set, and the difference between the maximum and minimum values of the values of metric B or metric C acquired and normalized by the metrics acquisition unit at a specified time is greater than or equal to a specified second percentage of the overall normalized size of the metrics, a control hysteresis is set by adding a first specified value to the normalized value of metric B and/or metric C determined to be the monitoring target, and subtracting a second specified value from the normalized value of metric A determined to be the monitoring target. An uncore frequency control method of an uncore frequency control device that controls an uncore frequency of a physical server that is a compute equipped with a Web service application, comprising:
The Uncore frequency control device includes:
collecting data including HW operation status data from the compute for a predetermined period of time;
a step of selecting, from among the collected data, data that is counted up over time as the metrics to be analyzed, normalizing the metrics using a Min-Max method, and classifying the metrics into a group of metrics A whose values increase as the load on the Web service application increases, a group of metrics B whose values decrease when the load increases and application performance degradation occurs, and a group of metrics C whose values converge when the load increases and application performance degradation occurs, selecting at least one metric B and/or metric C from the group of metrics B and the group of metrics C, and selecting one metric A from the group of metrics A whose normalized value is smaller than that of the selected metric B and/or metric C during a low load period before the application performance degradation occurs, and determining the selected metric to be monitored;
acquiring data of metric A, metric B and/or metric C to be monitored from the compute, and normalizing the data by the Min-Max method;
setting the compute uncore frequency to a configurable maximum value when either the normalized value of the metric B or the normalized value of the metric C is lower than the normalized value of the metric A, and setting the compute uncore frequency to a configurable minimum value when either the normalized value of the metric B or the normalized value of the metric C is not lower than the normalized value of the metric A;
An uncore frequency control method comprising the steps of: An uncore frequency control program for causing a computer to function as an uncore frequency control device according to any one of claims 1 to 4.

Images