BMC and operating system cooperative dynamic power scheduling method for heterogeneous GPU

Abstract

Embodiments of the present disclosure disclose a heterogeneous GPU-oriented BMC and operating system cooperative dynamic power scheduling method. A specific embodiment of the method comprises: performing timestamp alignment processing on hardware parameters and performance parameters to obtain a fusion decision vector; generating a hardware safety power upper limit according to temperature values and temperature rise rate values in the fusion decision vector; generating a performance demand power upper limit according to utilization and service priority in the fusion decision vector; generating a dynamic power wall according to the hardware safety power upper limit, the performance demand power upper limit and the factory power wall; performing frequency down processing on the target processor according to the actual power consumption and the dynamic power wall to obtain the actual power consumption after frequency reduction; and performing frequency recovery processing on the target processor to obtain the normal frequency after recovery. The embodiment relates to the technical field of computers, reduces the waste of computing resources, and shortens the response time of passive frequency reduction.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a dynamic power consumption scheduling method for BMC and operating system collaboration for heterogeneous GPUs. Background Technology

[0002] Deploying GPUs from different manufacturers and with different architectures simultaneously within a single host enables heterogeneous computing power fusion, improving server computing density and task processing capabilities. To ensure GPU hardware safety, real-time monitoring and control of GPU temperature and power consumption are necessary to prevent overheating or overpowering that could damage the device. Currently, the common approach for power scheduling between the Baseboard Management Controller (BMC) and Operating System (OS) of heterogeneous GPUs is as follows: the BMC monitors GPU hardware parameters such as temperature and power consumption and performs forced frequency reduction when these parameters exceed thresholds, while the OS independently performs performance scheduling based on GPU utilization and task load.

[0003] However, in practice, it has been found that when using the above method for power consumption scheduling, the following technical problems often arise: Because the BMC and OS lack data communication and state synchronization, neither can know the other's current control strategy. This leads to simultaneous triggering of hardware-level frequency reduction by the BMC and performance-level frequency increase by the OS, creating a decision conflict. This results in frequent frequency switching of the GPU within a short period, causing drastic fluctuations in GPU performance and power consumption, reducing the stability of business operations. Furthermore, since the BMC can only passively trigger frequency reduction when temperature or power consumption exceeds preset thresholds, it cannot proactively avoid overheating risks. This leads to frequent temperature spikes and sharp performance drops, resulting in significant waste of GPU computing resources, and the passive frequency reduction response time is relatively long.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a dynamic power scheduling method for BMC and operating system collaboration for heterogeneous GPUs to solve one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a method for dynamic power scheduling in collaboration between the BMC and the operating system for heterogeneous GPUs. The method includes: generating standard-format hardware parameters based on acquired private hardware parameters; performing timestamp alignment processing on the hardware parameters and acquired performance parameters to obtain a fusion decision vector; generating a hardware safety power limit based on the factory power limit and the temperature value and temperature rise rate value in the fusion decision vector; generating a performance requirement power limit based on the utilization rate and service priority in the fusion decision vector; generating a dynamic power limit based on the hardware safety power limit, the performance requirement power limit, and the factory power limit; performing frequency downscaling processing on the target processor based on the actual power consumption and the dynamic power limit to obtain the down-clocked actual power consumption; and performing frequency recovery processing on the target processor in response to detecting that the down-clocked actual power consumption meets a preset jitter condition to obtain the recovered normal frequency.

[0008] The above-described embodiments of this disclosure have the following beneficial effects: Through a dynamic power scheduling method for heterogeneous GPUs using BMC and operating system collaboration according to some embodiments of this disclosure, the waste of computing resources can be reduced, and the response time of passive frequency reduction can be shortened. The reason for the significant waste of computing resources and the long response time of passive frequency reduction is that, due to the lack of data communication and state synchronization between the BMC and the OS, neither can know the other's current control strategy. This leads to simultaneous triggering of hardware-level frequency reduction by the BMC and performance-level frequency increase by the OS, resulting in decision conflicts. This causes the GPU to frequently switch frequencies in a short period, causing drastic fluctuations in GPU performance and power consumption, reducing the stability of business operations. Simultaneously, since the BMC can only passively trigger frequency reduction after temperature or power consumption exceeds a preset threshold, it cannot proactively avoid over-temperature risks, leading to frequent temperature spikes and performance drops, resulting in severe waste of GPU computing resources and a long response time for passive frequency reduction. Based on this, the dynamic power scheduling method for heterogeneous GPUs using BMC and operating system collaboration according to some embodiments of this disclosure first generates standard-format hardware parameters based on the acquired private hardware parameters. Thus, standard-format hardware parameters can be obtained. Then, the hardware parameters and acquired performance parameters are timestamped to obtain a fusion decision vector. This yields the fused decision vector. Next, based on the factory power consumption limit and the temperature and temperature rise rate values ​​in the fusion decision vector, a hardware safety power consumption limit is generated. This yields the upper limit of the hardware safety power consumption. Next, based on the utilization rate and service priority in the fusion decision vector, a performance requirement power consumption limit is generated. This yields the upper limit of the performance requirement power consumption. Next, based on the hardware safety power consumption limit, the performance requirement power consumption limit, and the factory power consumption limit, a dynamic power consumption limit is generated. This yields the synthesized dynamic power consumption limit threshold. Next, based on the actual power consumption and the dynamic power consumption limit, the target processor's frequency is downgraded to obtain the downgraded actual power consumption. This yields the frequency downgraded actual power consumption. Finally, in response to the detection that the downgraded actual power consumption meets a preset jitter condition, the target processor's frequency is restored to its normal frequency. This yields the frequency restorationd actual power consumption. Because it doesn't simply optimize the control strategies of the BMC or OS independently, but instead integrates the hardware parameters collected by the BMC and the performance parameters collected by the OS into a unified decision vector, it generates a hardware safety power consumption limit based on temperature and temperature rise rate, and a performance requirement power consumption limit based on utilization and service priority. The minimum of these two limits and the factory power consumption wall is then taken as the dynamic power consumption wall, enabling data exchange between the BMC and OS and eliminating decision conflicts. Furthermore, it doesn't use a fixed power consumption wall threshold for frequency ramping and de-clocking control, but rather triggers frequency down-clocking in stages based on the dynamic power consumption wall. After frequency down-clocking, it uses preset jitter conditions to determine whether to restore the frequency, creating an interval between the trigger thresholds for frequency down-clocking and restoration.Therefore, cross-layer collaboration between the BMC and the OS can be achieved, proactively mitigating over-temperature risks, avoiding performance fluctuations caused by decision conflicts and frequent frequency switching, and preventing temperature spikes and response delays due to passive triggering. This reduces the waste of computing resources and shortens the response time of passive frequency reduction. Attached Figure Description

[0009] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0010] Figure 1 This is a flowchart of some embodiments of the BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs according to the present disclosure; Figure 2 This is a schematic diagram of some embodiments of the BMC and operating system collaborative dynamic power scheduling device for heterogeneous GPUs according to the present disclosure. Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0011] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0012] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0013] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0014] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0015] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0016] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0017] Figure 1 The flowchart 100 illustrates some embodiments of the BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs according to this disclosure. This BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs includes the following steps: Step 101: Generate hardware parameters in a standard format based on the obtained private hardware parameters.

[0018] In some embodiments, the execution entity (e.g., a computing device) of the BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs can generate standard-format hardware parameters based on the acquired private hardware parameters. These private hardware parameters can be raw parameters directly read by the baseboard management controller from the target processor. The target processor can be a graphics processor. Here, there is no limitation on the specific types of the target processor and the raw parameters. For example, the target processor can be an NVIDIA A100 graphics processor, and the raw parameters can be the temperature value, power consumption value, and temperature rise rate value reported by the graphics processor. The hardware parameters can be parameters that have undergone format standardization processing.

[0019] In addressing the technical challenges mentioned above, and considering the specific application scenario—a heterogeneous GPU deployment in a data center—the hardware parameter formats reported by GPUs from different manufacturers to the BMC via their proprietary drivers differ significantly. This often leads to the following technical problem: The proprietary data formats of GPUs from different manufacturers vary considerably. Without a unified format recognition and conversion mechanism, the BMC cannot correctly parse the temperature, power consumption, and temperature rise rate values ​​reported by each manufacturer, causing subsequent power scheduling decisions to fail due to inconsistent data formats. Furthermore, the proprietary data from each manufacturer may contain outliers or missing values. Directly using unverified raw data for scheduling can easily lead to incorrect decisions due to data quality issues, resulting in unnecessary frequency reductions or failure to trigger frequency throttling in a timely manner. This necessitates repeated data resampling and re-parsening, wasting significant computing resources and resulting in low overall system power scheduling efficiency. To meet the following requirements for this application scenario: adaptability to parsing proprietary data formats from different GPU manufacturers, adaptability to parsing data structures of different formats, and adaptability to the automatic detection and correction of outlier data, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity can generate standard-format hardware parameters based on the acquired private hardware parameters through the following steps: The first step involves parsing the aforementioned private hardware parameters to obtain their data structure information. This data structure information represents the start and end positions, data types, and byte lengths of each data field within the private hardware parameters. For example, the data structure information could be: "Temperature field: start position is byte 1, end position is byte 2, data type is unsigned integer, byte length is 2; Power consumption field: start position is byte 3, end position is byte 4, data type is unsigned integer, byte length is 2; Temperature rise rate field: start position is byte 5, end position is byte 6, data type is unsigned integer, byte length is 2." In practice, the executing entity first obtains the data format definition corresponding to the target processor from the local storage medium. Then, according to the preset data format definition, starting from the first byte of the private hardware parameters, the start and end positions, data types, and byte lengths of each data field are determined sequentially, resulting in the start and end positions, data types, and byte lengths of each data field. Finally, the start and end positions, data types, and byte lengths of each data field are recorded as data structure information. The aforementioned data format definition can be the arrangement rules and data type definition of each data field. For example, a preset data format definition could be: "Temperature values ​​are stored as unsigned integers in the first and second bytes of the byte sequence, power consumption values ​​are stored as unsigned integers in the third and fourth bytes of the byte sequence, and temperature rise rate values ​​are stored as unsigned integers in the fifth and sixth bytes of the byte sequence." The aforementioned local storage medium can be the physical medium used to store the data. Here, the specific type of the aforementioned local storage medium is not limited; for example, the local storage medium can be flash memory. It should be noted that different manufacturers have different data format definitions. The aforementioned byte sequence can be a sequence of data composed of multiple consecutively arranged bytes.

[0020] The second step involves extracting values ​​from the aforementioned private hardware parameters based on the data structure information, yielding the actual values ​​for each data field. These actual values ​​can be the byte sequences of each data field in the data structure information converted according to their corresponding data types. In practice, the executing entity first extracts the corresponding byte sequences from the private hardware parameters based on the start and end positions of each data field recorded in the data structure information. Then, according to the data type of each data field recorded in the data structure information, the corresponding byte sequences are converted into numerical values ​​to obtain the actual values ​​for each data field. These data types can be unsigned integers, signed integers, or floating-point numbers.

[0021] The third step is to generate numerical range information based on the acquired historical parameter statistics. The historical parameter statistics can be the values ​​of each data field of the target processor within a historical time period. The numerical range information can represent the interval formed by the minimum and maximum values ​​of each data field of the target processor within the historical time period. The historical time period can be a preset duration prior to the current moment. Here, the specific value of the preset duration is not limited; for example, the preset duration can be 7 days. In practice, firstly, the executing entity can obtain the values ​​of each data field of the target processor within the historical time period, obtaining each value. Then, the interval formed by the minimum and maximum values ​​of these values ​​is determined as the numerical range information.

[0022] The fourth step involves performing anomaly detection processing on the actual values ​​of each data field based on the aforementioned numerical range information, obtaining anomaly detection results. These anomaly detection results characterize whether the actual values ​​of each data field are abnormal. The anomaly detection results can be either a first detection result or a second detection result. The first detection result characterizes whether the actual values ​​of each data field are abnormal. The second detection result characterizes whether the actual values ​​of each data field are not abnormal. In practice, the executing entity can compare the actual values ​​of each data field with the corresponding minimum and maximum values ​​in the aforementioned numerical range information. In response to determining that the actual value exceeds the aforementioned numerical range information, the first detection result is determined as the anomaly detection result for the aforementioned data field; in response to determining that the actual value does not exceed the aforementioned numerical range information, the second detection result is determined as the anomaly detection result for the aforementioned data field.

[0023] Fifth, based on the above anomaly detection results, the aforementioned private hardware parameters are corrected to obtain the corrected hardware parameters. In practice, in response to determining the above anomaly detection result as the first detection result, the executing entity can use the average value of the abnormal data field over a historical period as the replacement value, and replace the above abnormal data field with the replacement value to obtain the corrected hardware parameters. The above abnormal data field can be the data field in the above private hardware parameters whose anomaly detection result is the first detection result.

[0024] Step 6: Perform dimension conversion on the modified hardware parameters to obtain the dimension-converted hardware parameters. These dimension-converted hardware parameters can be obtained by converting the modified hardware parameters according to preset standard dimension information. The preset standard dimension information can include standard unit and standard dimension range. The standard unit can be a pre-defined standard unit category, such as Celsius for temperature and watts for power consumption. The standard dimension range can be a pre-defined standard numerical range, such as -10℃ to 100℃ for temperature. In practice, firstly, the executing entity can obtain the current unit and current value of each data field in the modified hardware parameters. The current unit can be the unit currently used for each data field in the modified hardware parameters. The current value can be the value of each data field in the modified hardware parameters. Then, based on the preset standard dimension information, the standard unit corresponding to each data field is determined using a lookup table. In response to the determination that the current unit of measurement differs from the standard unit of measurement, the current value is converted according to the conversion ratio between the current and standard units to obtain a standard unit of measurement value. For example, if the current unit of measurement is milliwatt-hours, the current value is divided by 1000 to obtain a standard unit of measurement value in watts. Then, the standard unit of measurement value is compared with the standard unit of measurement range. In response to the determination that the standard unit of measurement value exceeds the standard unit of measurement range, the standard unit of measurement value is corrected to the boundary value of the standard unit of measurement range to obtain the hardware parameters after unit conversion. The correction may be in response to the determination that the standard unit of measurement value is less than the minimum value of the standard unit of measurement range, setting the standard unit of measurement value to the minimum value; or in response to the determination that the standard unit of measurement value is greater than the maximum value of the standard unit of measurement range, setting the standard unit of measurement value to the maximum value.

[0025] The seventh step involves formatting the hardware parameters after the above-mentioned dimension conversion to obtain standard-format hardware parameters. In practice, the executing entity can arrange the hardware parameters after the dimension conversion according to the order in the above data structure information to form standard-format hardware parameters.

[0026] The above-described technical solution, as an inventive point of this disclosure, addresses technical problem two: "wasting a large amount of computing resources, resulting in low overall system power scheduling efficiency." The reasons for this waste of computing resources and low overall system power scheduling efficiency are as follows: Different manufacturers' GPUs have significantly different proprietary data formats. Without a unified format recognition and conversion mechanism, the BMC cannot correctly parse the temperature, power consumption, and temperature rise rate values ​​reported by each manufacturer, causing subsequent power scheduling decisions to fail due to inconsistent data formats. Furthermore, each manufacturer's proprietary data may contain outliers or missing values. Directly using unverified raw data for scheduling can easily lead to decision errors due to data quality issues, resulting in unnecessary frequency reductions or failure to trigger frequency reduction in a timely manner. This necessitates repeated data resampling and re-parsening, wasting a large amount of computing resources and causing low overall system power scheduling efficiency. Solving these factors can reduce wasted computing resources and improve overall system power scheduling efficiency. To achieve this effect, the disclosed BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs obtains the data structure information of private hardware parameters through format parsing. This accurately identifies the start and end positions, data types, and byte lengths of each data field, enabling the BMC to correctly read the temperature, power consumption, and temperature rise rate values ​​reported by GPUs from different manufacturers. Furthermore, based on the numerical range information generated from historical parameter statistics, anomaly detection is performed on the actual values ​​of each data field, and abnormal data is corrected. This effectively removes outliers and fills in missing values, eliminating the impact of data quality issues on subsequent power scheduling decisions. In addition, the corrected hardware parameters undergo dimension conversion, unifying the proprietary dimensions of various manufacturers into standard dimensions. The converted hardware parameters are then formatted to generate standard-format hardware parameters, allowing the upper-layer scheduling logic to perform power consumption calculations and decisions using a unified data format, eliminating the need to develop separate parsing logic for different GPU manufacturers. This reduces the waste of computing resources caused by inconsistent data formats and repeated resampling, improving the overall power scheduling efficiency of the system.

[0027] Step 102: Perform timestamp alignment processing on the hardware parameters and the acquired performance parameters to obtain the fusion decision vector.

[0028] In some embodiments, the execution entity may perform timestamp alignment processing on the hardware parameters and the acquired performance parameters to obtain a fusion decision vector. The hardware parameters may include temperature, power consumption, and temperature rise rate. The temperature may be the temperature of the target processor. The power consumption may be the power consumption of the target processor. The temperature rise rate may be the change in temperature per unit time. The specific type of the target processor is not limited here; for example, the target processor may be a graphics processing unit (GPU). The performance parameters may include utilization and service priority. The utilization may be the percentage of computing resources occupied by the target processor. The service priority may be the level of importance of the task running on the target processor. The running task and its corresponding level are not limited here; for example, the running task may be a training task, and the corresponding level may be level one (high priority). The fusion decision vector may be an array composed of the temperature, power consumption, temperature rise rate, utilization, and service priority arranged in sequence.

[0029] In addressing the technical problems mentioned above, and considering the application scenario—large-scale AI training clusters where the BMC and OS independently collect GPU hardware and performance parameters for power scheduling decisions—the following technical problem often arises: In large-scale AI training clusters, the BMC and OS maintain independent time domains, leading to discrepancies in the timestamps of their collected data. This results in misalignment of temperature and utilization in the fused decision vector on the time axis. When the temperature has increased but the utilization data remains the old value from a low-load period, the system misjudges the current load state and fails to trigger frequency reduction in time. The GPU continues to run at high load, causing the temperature to peak and triggering forced frequency locking, resulting in training task interruption. This necessitates reloading model parameters and datasets, leading to poor accuracy in overall cluster power scheduling and wasting significant computing resources. To meet the following requirements for this application scenario: adapting to the asynchronous time domains of the BMC and OS on different nodes in a large-scale cluster, and adapting to varying time deviations across nodes, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity may perform timestamp alignment processing on the aforementioned hardware parameters and the acquired performance parameters through the following steps to obtain a fused decision vector: The first step is to generate a time deviation value based on the first timestamp corresponding to the aforementioned hardware parameters and the second timestamp corresponding to the aforementioned performance parameters. The first timestamp can be the moment when the baseboard management controller acquires the aforementioned hardware parameters. The second timestamp can be the moment when the operating system acquires the aforementioned performance parameters. The time deviation value can be the absolute value of the difference between the first timestamp and the second timestamp. In practice, firstly, the executing entity can determine the difference between the first timestamp and the second timestamp as a first value. Then, the absolute value of the first value is determined as the time deviation value.

[0030] The second step is to determine the unified alignment time based on the aforementioned time deviation value and time deviation tolerance. The aforementioned time deviation tolerance can be a pre-set threshold for allowable deviation. For example, the time deviation tolerance can be 100 milliseconds. The aforementioned unified alignment time can be the moment used to align the aforementioned hardware parameters and performance parameters. In practice, the executing entity can compare the aforementioned time deviation value with the aforementioned time deviation tolerance. In response to determining that the aforementioned time deviation value is less than or equal to the aforementioned time deviation tolerance, the aforementioned first timestamp is determined as the unified alignment time; in response to determining that the aforementioned time deviation value is greater than the aforementioned time deviation tolerance, the sum of the aforementioned first value and the aforementioned second timestamp is determined as the unified alignment time.

[0031] The third step involves aligning the temperature, power consumption, temperature rise rate, utilization rate, and service priority values ​​according to the unified alignment time mentioned above, to obtain the fusion decision vector. In practice, the executing entity can arrange the temperature, power consumption, temperature rise rate, utilization rate, and service priority values ​​in sequence to obtain the fusion decision vector.

[0032] The above technical solution, as an inventive point of this disclosure, solves technical problem three: "poor accuracy of overall cluster power consumption scheduling, resulting in a significant waste of computing resources." The reasons for this poor accuracy and waste of computing resources are as follows: In large-scale AI training clusters, the BMC and OS each maintain independent time domains, leading to discrepancies in the timestamps of their collected data. This results in misalignment of temperature and utilization in the fused decision vector on the time axis. When the temperature has increased but the utilization data remains the old value from a low-load period, the system misjudges the current load state and fails to trigger frequency reduction in time. The GPU continues to run at high load, causing the temperature to peak and triggering forced frequency locking, resulting in training task interruption. This necessitates reloading model parameters and datasets, leading to poor accuracy in overall cluster power consumption scheduling and a significant waste of computing resources. Solving these factors can improve the accuracy of overall cluster power consumption scheduling and reduce wasted computing resources. To achieve this effect, the disclosed dynamic power scheduling method for heterogeneous GPUs, which coordinates BMC and operating system, determines the degree of deviation between the BMC and OS data on the time axis by obtaining the first timestamp corresponding to the hardware parameters and the second timestamp corresponding to the performance parameters and calculating the time deviation value. Furthermore, based on the comparison between the time deviation value and the time deviation tolerance, a unified alignment time is determined, aligning the hardware parameters and performance parameters to the same moment. This avoids misjudgments of load status caused by time axis misalignment, reduces training task interruptions and reloading due to erroneous decisions, thereby improving the accuracy of overall cluster power scheduling and reducing wasted computing resources.

[0033] Step 103: Generate the hardware safe power consumption limit based on the factory power consumption limit and the temperature value and temperature rise rate value in the fusion decision vector.

[0034] In some embodiments, the execution entity can generate a hardware-safe power consumption limit based on the factory power consumption limit and the temperature and temperature rise rate values ​​in the fusion decision vector. The factory power consumption limit can be a threshold representing the maximum power consumption set at the factory for the target processor. For example, the factory power consumption limit could be 400 watts. The hardware-safe power consumption limit can be the maximum permissible power consumption value to ensure the hardware safety of the target processor.

[0035] In some optional implementations of certain embodiments, the aforementioned execution entity can generate a hardware safe power consumption limit based on the factory power consumption limit and the temperature value and temperature rise rate value in the aforementioned fusion decision vector through the following steps: The first step is to generate a temperature coefficient based on the aforementioned temperature value and a preset temperature mapping relationship. This preset temperature mapping relationship can be a correspondence between the temperature value's range and the temperature coefficient. For example, the preset temperature mapping relationship could be "Temperature value range: [0℃, 60℃]; Temperature coefficient: 0.9". The temperature coefficient can be a factor used to reduce the factory power consumption limit corresponding to the aforementioned temperature value. In practice, firstly, the executing entity can determine the range of the temperature value within the preset temperature mapping relationship as the first range. Then, the temperature coefficient corresponding to the first range is determined as the temperature coefficient. It should be noted that the temperature coefficient can decrease as the temperature value increases.

[0036] The second step involves generating a temperature rise rate coefficient based on the aforementioned temperature rise rate value and the preset temperature rise rate mapping relationship. This preset temperature rise rate mapping relationship can be a correspondence between the interval containing the aforementioned temperature rise rate value and the temperature rise rate coefficient. For example, the preset temperature rise rate mapping relationship could be "Temperature rise rate value interval: [1℃ / s, 2℃ / s]; Temperature rise rate coefficient: 0.8". The temperature rise rate coefficient can be a coefficient used to reduce the factory power consumption limit corresponding to the aforementioned temperature rise rate value. In practice, firstly, the executing entity can determine the interval containing the aforementioned temperature rise rate value in the preset temperature rise rate mapping relationship as the second interval. Then, the temperature rise rate coefficient corresponding to the second interval is determined as the temperature rise rate coefficient. It should be noted that the temperature rise rate coefficient decreases as the aforementioned temperature rise rate value increases.

[0037] The third step is to determine the safety factor based on the temperature coefficient and the temperature rise rate coefficient mentioned above.

[0038] The aforementioned safety factor can be a coefficient used to reduce the aforementioned factory power consumption limit. In practice, the implementing entity can determine the safety factor as the minimum value between the aforementioned temperature coefficient and the aforementioned temperature rise rate coefficient. It should be noted that the aforementioned safety factor is negatively correlated with the aforementioned temperature value, and the aforementioned safety factor is negatively correlated with the aforementioned temperature rise rate value.

[0039] The fourth step is to determine the upper limit of hardware safe power consumption by multiplying the above-mentioned factory power consumption limit and the above-mentioned safety factor.

[0040] Step 104: Generate the upper limit of power consumption for performance requirements based on the utilization rate and business priority in the fusion decision vector.

[0041] In some embodiments, the execution entity may generate a performance requirement power consumption cap based on the utilization and service priority in the fusion decision vector. This performance requirement power consumption cap may be the maximum allowable power consumption value required to meet the performance requirements of the task running on the target processor.

[0042] In some optional implementations of certain embodiments, the aforementioned execution entity can generate a performance requirement power consumption ceiling based on the utilization and service priority in the aforementioned fusion decision vector through the following steps: The first step is to generate a target priority coefficient based on the aforementioned business priorities. This target priority coefficient can be an amplification of the factory power consumption limit. In practice, the executing entity first determines the level of the aforementioned business priority in a preset priority mapping relationship as the first level. Then, the priority coefficient corresponding to the first level is determined as the target priority coefficient. The preset priority mapping relationship can be a correspondence between the levels of the aforementioned business priorities and the aforementioned priority coefficients. For example, the preset priority mapping relationship could be: "Business priority level: Level 1; Priority coefficient: 1.1, Business priority level: Level 2; Priority coefficient: 0.95, Business priority level: Level 3; Priority coefficient: 0.8". It should be noted that the target priority coefficient is positively correlated with the aforementioned business priorities.

[0043] The second step is to determine the upper limit of power consumption for performance requirements by multiplying the above-mentioned factory power consumption limit, the above-mentioned utilization rate, and the above-mentioned target priority coefficient.

[0044] Step 105: Generate a dynamic power consumption wall based on the hardware security power consumption limit, the performance requirement power consumption limit, and the factory power consumption wall.

[0045] In some embodiments, the execution entity may generate a dynamic power wall based on the hardware security power consumption limit, the performance requirement power consumption limit, and the factory power consumption wall. The dynamic power wall may be the final upper limit value used for power scheduling of the target processor.

[0046] In some optional implementations of certain embodiments, the aforementioned execution entity can generate a dynamic power wall based on the aforementioned hardware security power consumption limit, the aforementioned performance requirement power consumption limit, and the factory power consumption wall through the following steps: The first step is to determine the target power consumption value based on the aforementioned hardware safety power consumption limit, performance requirement power consumption limit, and factory power consumption limit. The target power consumption value can be the minimum value among these three: the hardware safety power consumption limit, the performance requirement power consumption limit, and the factory power consumption limit. In practice, the executing entity can determine the target power consumption value as the minimum value among these three.

[0047] The second step is to determine the target power consumption value mentioned above as the dynamic power consumption wall.

[0048] Step 106: Based on the actual power consumption and the dynamic power limit, perform frequency reduction processing on the target processor to obtain the actual power consumption after frequency reduction.

[0049] In some embodiments, the execution entity may perform frequency reduction processing on the target processor based on the actual power consumption and the dynamic power limit, thereby obtaining the actual power consumption after frequency reduction. The actual power consumption may be the power consumption of the target processor at the current moment.

[0050] In some optional implementations of certain embodiments, the aforementioned execution entity may perform frequency reduction processing on the target processor based on the actual power consumption and the aforementioned dynamic power limit through the following steps to obtain the actual power consumption after frequency reduction: The first step involves determining that the actual power consumption is greater than or equal to a first value and less than the dynamic power limit, setting a slight frequency reduction as the target frequency reduction level. The first value can be the product of the dynamic power limit and the target value. The target value can be 0.9.

[0051] The second step involves determining that the actual power consumption is greater than or equal to the dynamic power limit, and setting a moderate frequency reduction as the target frequency reduction level. Both the mild and moderate frequency reduction levels can be considered as levels of frequency reduction applied to the target processor. It should be noted that the frequency reduction magnitude corresponding to the mild frequency reduction is smaller than that corresponding to the moderate frequency reduction. The frequency reduction magnitude can be the percentage reduction in the target processor's current operating frequency. For example, the frequency reduction magnitude could be 20%.

[0052] The third step involves adjusting the frequency of the target processor according to the target frequency reduction level to obtain the actual power consumption after frequency reduction. In practice, firstly, the executing entity can determine the frequency reduction magnitude corresponding to the target frequency reduction level from a preset frequency reduction mapping relationship. Then, the operating frequency of the target processor is reduced by the aforementioned frequency reduction magnitude to obtain the reduced operating frequency as the actual power consumption after frequency reduction. The preset frequency reduction mapping relationship can be a correspondence between the target frequency reduction level and the frequency reduction magnitude. For example, the preset frequency reduction mapping relationship can be "Target frequency reduction level: slight frequency reduction; frequency reduction magnitude: 12%", "Target frequency reduction level: moderate frequency reduction; frequency reduction magnitude: 30%".

[0053] In addressing the aforementioned technical issues in the process of adopting technical solutions, and considering the application scenario—GPUs operating at full load for extended periods during large and complex model training tasks—the following technical problem often arises: Temperature sensors deployed near the core area, due to prolonged exposure to high temperatures, experience a gradual drift in measurement accuracy with age, often resulting in readings lower than the actual temperature. This can lead to failure to trigger forced frequency locking in a timely manner, causing GPU temperature spikes or even damage. Simultaneously, temperature sensors deployed around the memory may experience transient reading jumps due to airflow interference from the cooling duct, triggering unnecessary forced frequency locking, interrupting training tasks, requiring model and dataset reloading, wasting significant computing resources, and reducing overall system power scheduling efficiency, resulting in poor continuity and stability of training tasks. To address the following requirements for this application scenario: adapting to accuracy drift caused by sensor aging and adapting to reading jumps caused by airflow interference, we have decided to adopt the following solution: Optionally, after step 106, the aforementioned executing entity may also perform the following steps: The first step is to acquire multiple current temperature values ​​collected by each temperature sensor. Each of these current temperature values ​​can be the temperature value collected by each of the aforementioned temperature sensors at the current moment. These temperature sensors can be deployed at different locations relative to the target processor. The specific type of temperature sensor is not limited here; for example, the temperature sensor can be a thermistor type or a thermocouple type.

[0054] The second step involves determining the positional weights of each temperature sensor based on their deployment locations on the target processor. These deployment locations can be on or around the chip of the target processor. The positional weights represent the weight of the temperature values ​​collected by each sensor in the fusion processing. The core region can be the area of ​​the target processor with the highest heat generation, such as the area where the computing core of a graphics processing unit (GPU) is located. In practice, the executing entity can obtain the distances between the deployment locations of each temperature sensor and the core region of the target processor. Then, based on a preset distance-weight mapping relationship, the positional weights corresponding to each distance are determined. This preset distance-weight mapping relationship can be a correspondence between the distance's range and its positional weight. For example, the preset distance-weight mapping relationship could be: "Distance [0,5], positional weight 1.0; distance [5,10], positional weight 0.8; distance [10,15], positional weight 0.6".

[0055] The third step involves acquiring the historical measurement accuracy information of each temperature sensor within a preset historical time period, and determining the accuracy weight of each temperature sensor based on this historical measurement accuracy information. The preset historical time period can be a time window preceding the current moment, for example, a 24-hour window. The historical measurement accuracy information can be the average of the absolute values ​​of the differences between the historical measurement values ​​of each temperature sensor and a reference value within the preset historical time period. The historical measurement values ​​can be the temperature values ​​collected by each temperature sensor within the preset historical time period. The reference value can be the temperature value measured by a calibrated temperature sensor under the same conditions. The accuracy weight can be a coefficient characterizing the measurement reliability of each temperature sensor; the higher the accuracy of the historical measurement values, the higher the accuracy weight. In practice, firstly, the executing entity can acquire multiple historical measurement values ​​of each temperature sensor within the preset historical time period, as well as the corresponding reference values, to obtain multiple historical measurement values ​​and corresponding reference values ​​for each temperature sensor. Then, for each of the temperature sensors, the following steps are performed: For each historical measurement value, the difference between the historical measurement value and the corresponding reference temperature value is determined as a third value, thus obtaining each third value. Next, the average of the aforementioned third values ​​is determined as the average deviation value. Then, the obtained average deviation values ​​are normalized to obtain the accuracy weight of each temperature sensor. It should be noted that the above normalization process can be as follows: first, divide the average deviation value of each temperature sensor by the sum of the average deviation values ​​of all temperature sensors to obtain the initial weight of each temperature sensor; then, divide each initial weight by the sum of the initial weights to obtain the accuracy weight of each temperature sensor.

[0056] The fourth step involves generating a comprehensive confidence weight for each temperature sensor based on its position and accuracy weights. This comprehensive confidence weight is a coefficient characterizing the reliability of each temperature sensor in the weighted aggregation process. In practice, the executing entity can determine the comprehensive confidence weight by summing the position and accuracy weights of each temperature sensor. It should be noted that each temperature sensor corresponds to a different comprehensive confidence weight.

[0057] The fifth step involves weighted aggregation of the multiple current temperature values ​​based on the comprehensive confidence weights of each temperature sensor, yielding a fused temperature value. This fused temperature value can be the result of weighted aggregation of the multiple current temperature values. In practice, the executing entity can first determine the weighted temperature value of each temperature sensor by multiplying its current temperature value by its corresponding comprehensive confidence weight. Then, the average of these weighted temperature values ​​is used to determine the fused temperature value.

[0058] Step 6: Based on the comprehensive confidence weights of the various temperature sensors, perform a confidence assessment on the fused temperature value to obtain a confidence rating for the fused temperature value. This confidence rating characterizes the level of reliability of the fused temperature value. The confidence rating can be either Level 1 or Level 2. Level 1 indicates that the confidence of the fused temperature value is at Level 1 (high level). Level 2 indicates that the confidence of the fused temperature value is at Level 2 (low level). In practice, firstly, the executing entity can determine the total confidence weight by summing the comprehensive confidence weights of the various temperature sensors. Then, in response to determining that the total confidence weight is greater than a preset confidence threshold, Level 1 is determined as the confidence rating of the fused temperature value; in response to determining that the total confidence weight is less than or equal to the preset confidence threshold, Level 2 is determined as the confidence rating of the fused temperature value. For example, the preset confidence threshold can be 0.8.

[0059] Step 7: Based on the aforementioned credibility identifier and target verification method, the fused temperature value is verified and corrected to obtain the verified temperature value. The verified temperature value can be the temperature value obtained after verifying and correcting the fused temperature value. The target verification method can be either a first verification method or a second verification method. In practice, in response to determining the aforementioned credibility identifier as a first level, the fused temperature value is verified and corrected using the first verification method to obtain the verified temperature value; in response to determining the aforementioned credibility identifier as a second level, the fused temperature value is verified and corrected using the second verification method to obtain the verified temperature value. The first verification method can be to use the fused temperature value as the verified temperature value. The second verification method can be: First, obtain multiple historical temperature values ​​prior to the current time. Then, perform linear fitting on the multiple historical temperature values ​​to obtain a temperature change trend line. Next, substitute the current time into the temperature change trend line to obtain an extrapolated temperature value. Finally, determine the verified temperature value by weighted averaging the fused temperature value and the extrapolated temperature value.

[0060] Step 8: Based on the verified temperature value and the current temperature rise rate value, perform forced frequency locking on the target processor. The current temperature rise rate value can be the temperature rise rate value at the current moment. The forced frequency locking process can be an operation where the substrate management controller reduces the operating frequency of the target processor to below a preset safe frequency. For example, the preset safe frequency can be 50% of the current operating frequency of the target processor. In practice, forced frequency locking is performed on the target processor in response to determining that the verified temperature value is greater than or equal to a preset critical temperature, or that the temperature rise rate value is greater than a preset rate threshold.

[0061] The above technical solution, as an inventive point of this disclosure, solves technical problem four: "wasting a large amount of computing resources and leading to a decrease in the overall power consumption scheduling efficiency of the system, resulting in poor continuity and stability of training tasks." The reasons for this waste of computing resources, decreased overall power consumption scheduling efficiency, and poor continuity and stability of training tasks are as follows: Temperature sensors deployed near the core area are exposed to high temperatures for extended periods, causing their measurement accuracy to gradually drift with age, easily resulting in readings lower than the actual temperature. This leads to the failure of forced frequency locking to trigger in a timely manner, causing GPU temperature spikes or even damage. Simultaneously, temperature sensors deployed around the memory may experience transient reading jumps due to airflow interference in the cooling duct, triggering unnecessary forced frequency locking, causing training task interruptions, requiring reloading of the model and dataset, wasting a large amount of computing resources, and resulting in a decrease in the overall power consumption scheduling efficiency of the system, leading to poor continuity and stability of training tasks. Solving these factors can reduce the waste of computing resources, improve the overall power consumption scheduling efficiency of the system, and enhance the continuity and stability of training tasks. To achieve this effect, the disclosed BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs acquires current temperature values ​​from multiple temperature sensors and determines position weights and accuracy weights based on the deployment location and historical measurement accuracy of each sensor. This comprehensively reflects the importance of each sensor in spatial layout and the reliability of the measurement data. Furthermore, the position weights and accuracy weights are fused to generate a comprehensive confidence weight, and multiple current temperature values ​​are weighted and aggregated based on this weight to obtain a fused temperature value. This suppresses reading deviations caused by aging drift or airflow interference from a single sensor. In addition, the credibility of the fused temperature value is evaluated based on the comprehensive confidence weight, and a corresponding verification method is selected based on the credibility identifier to verify and correct the fused temperature value. The verified temperature value is used for forced frequency locking, avoiding false or missed triggers of forced frequency locking due to sensor data quality issues. Therefore, it reduces the wasted computing resources caused by training task interruptions due to false triggers, improves the overall power scheduling efficiency of the system, and enhances the continuity and stability of the training task.

[0062] Step 107: In response to the detection that the actual power consumption after frequency reduction meets the preset jitter condition, frequency recovery processing is performed on the target processor to obtain the normal frequency after recovery.

[0063] In some embodiments, in response to detecting that the actual power consumption after frequency reduction meets a preset jitter condition, the execution entity can perform frequency recovery processing on the target processor to obtain a restored normal frequency. The preset jitter condition can be that the actual power consumption after frequency reduction is less than or equal to a second value. The second value can be the difference between the dynamic power limit and a preset anti-jitter difference. The preset anti-jitter difference can be a pre-set value. Here, the specific value of the preset anti-jitter difference is not limited; for example, the preset anti-jitter difference can be 15 watts. The normal frequency can be the operating frequency of the target processor before the frequency reduction processing is performed. In practice, the execution entity can restore the operating frequency of the target processor at the current moment to a normal frequency to perform frequency recovery processing on the target processor to obtain a restored normal frequency.

[0064] The above-described embodiments of this disclosure have the following beneficial effects: Through a dynamic power scheduling method for heterogeneous GPUs using BMC and operating system collaboration according to some embodiments of this disclosure, the waste of computing resources can be reduced, and the response time of passive frequency reduction can be shortened. The reason for the significant waste of computing resources and the long response time of passive frequency reduction is that, due to the lack of data communication and state synchronization between the BMC and the OS, neither can know the other's current control strategy. This leads to simultaneous triggering of hardware-level frequency reduction by the BMC and performance-level frequency increase by the OS, resulting in decision conflicts. This causes the GPU to frequently switch frequencies in a short period, causing drastic fluctuations in GPU performance and power consumption, reducing the stability of business operations. Simultaneously, since the BMC can only passively trigger frequency reduction after temperature or power consumption exceeds a preset threshold, it cannot proactively avoid over-temperature risks, leading to frequent temperature spikes and performance drops, resulting in severe waste of GPU computing resources and a long response time for passive frequency reduction. Based on this, the dynamic power scheduling method for heterogeneous GPUs using BMC and operating system collaboration according to some embodiments of this disclosure first generates standard-format hardware parameters based on the acquired private hardware parameters. Thus, standard-format hardware parameters can be obtained. Then, the hardware parameters and acquired performance parameters are timestamped to obtain a fusion decision vector. This yields the fused decision vector. Next, based on the factory power consumption limit and the temperature and temperature rise rate values ​​in the fusion decision vector, a hardware safety power consumption limit is generated. This yields the upper limit of the hardware safety power consumption. Next, based on the utilization rate and service priority in the fusion decision vector, a performance requirement power consumption limit is generated. This yields the upper limit of the performance requirement power consumption. Next, based on the hardware safety power consumption limit, the performance requirement power consumption limit, and the factory power consumption limit, a dynamic power consumption limit is generated. This yields the synthesized dynamic power consumption limit threshold. Next, based on the actual power consumption and the dynamic power consumption limit, the target processor's frequency is downgraded to obtain the downgraded actual power consumption. This yields the frequency downgraded actual power consumption. Finally, in response to the detection that the downgraded actual power consumption meets a preset jitter condition, the target processor's frequency is restored to its normal frequency. This yields the frequency restorationd actual power consumption. Because it doesn't simply optimize the control strategies of the BMC or OS independently, but instead integrates the hardware parameters collected by the BMC and the performance parameters collected by the OS into a unified decision vector, it generates a hardware safety power consumption limit based on temperature and temperature rise rate, and a performance requirement power consumption limit based on utilization and service priority. The minimum of these two limits and the factory power consumption wall is then taken as the dynamic power consumption wall, enabling data exchange between the BMC and OS and eliminating decision conflicts. Furthermore, it doesn't use a fixed power consumption wall threshold for frequency ramping and de-clocking control, but rather triggers frequency down-clocking in stages based on the dynamic power consumption wall. After frequency down-clocking, it uses preset jitter conditions to determine whether to restore the frequency, creating an interval between the trigger thresholds for frequency down-clocking and restoration.Therefore, cross-layer collaboration between the BMC and the OS can be achieved, proactively mitigating over-temperature risks, avoiding performance fluctuations caused by decision conflicts and frequent frequency switching, and preventing temperature spikes and response delays due to passive triggering. This reduces the waste of computing resources and shortens the response time of passive frequency reduction.

[0065] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a BMC and operating system collaborative dynamic power scheduling method for heterogeneous GPUs. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0066] like Figure 2 As shown, some embodiments of the BMC and operating system collaborative dynamic power scheduling device 200 for heterogeneous GPUs include: a first generation unit 201, a first processing unit 202, a second generation unit 203, a third generation unit 204, a fourth generation unit 205, a second processing unit 206, and a third processing unit 207. The system comprises the following components: a first generation unit 201, configured to generate standard-format hardware parameters based on acquired private hardware parameters; a first processing unit 202, configured to perform timestamp alignment processing on the hardware parameters and acquired performance parameters to obtain a fusion decision vector; a second generation unit 203, configured to generate a hardware safety power consumption limit based on the factory power consumption limit and the temperature and temperature rise rate values ​​in the fusion decision vector; a third generation unit 204, configured to generate a performance requirement power consumption limit based on the utilization rate and service priority in the fusion decision vector; a fourth generation unit 205, configured to generate a dynamic power consumption limit based on the hardware safety power consumption limit, the performance requirement power consumption limit, and the factory power consumption limit; a second processing unit 206, configured to perform frequency down-regulation processing on the target processor based on the actual power consumption and the dynamic power consumption limit to obtain the actual power consumption after frequency reduction; and a third processing unit 207, configured to perform frequency recovery processing on the target processor in response to detecting that the actual power consumption after frequency reduction meets a preset jitter condition to obtain the recovered normal frequency.

[0067] It is understandable that the various units and references described in the BMC and operating system collaborative dynamic power scheduling device 200 for heterogeneous GPUs are... Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method are also applicable to the BMC and operating system collaborative dynamic power scheduling device 200 for heterogeneous GPUs and the units contained therein, and will not be repeated here.

[0068] The following is for reference. Figure 3It shows a schematic diagram of the structure of an electronic device 300 (e.g., a computing device) suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0069] like Figure 3 As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0070] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0071] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0072] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0073] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0074] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: generate standard-format hardware parameters based on acquired private hardware parameters; perform timestamp alignment processing on the aforementioned hardware parameters and acquired performance parameters to obtain a fusion decision vector; generate a hardware safety power consumption limit based on the factory power consumption limit and the temperature and temperature rise rate values ​​in the aforementioned fusion decision vector; generate a performance requirement power consumption limit based on the utilization rate and service priority in the aforementioned fusion decision vector; generate a dynamic power consumption limit based on the aforementioned hardware safety power consumption limit, the aforementioned performance requirement power consumption limit, and the aforementioned factory power consumption limit; perform frequency downsampling processing on the target processor based on the actual power consumption and the aforementioned dynamic power consumption limit to obtain the actual power consumption after frequency reduction; and, in response to detecting that the actual power consumption after frequency reduction meets a preset jitter condition, perform frequency recovery processing on the target processor to obtain the restored normal frequency.

[0075] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0076] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0077] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a first generation unit, a first processing unit, a second generation unit, a third generation unit, a fourth generation unit, a second processing unit, and a third processing unit. The names of these units do not necessarily limit the specific unit; for example, the first generation unit may also be described as "a unit that generates hardware parameters in a standard format based on acquired proprietary hardware parameters."

[0078] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0079] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A dynamic power scheduling method for BMC and operating system collaboration for heterogeneous GPUs, characterized in that, include: Based on the acquired private hardware parameters, generate hardware parameters in a standard format; The hardware parameters and the acquired performance parameters are timestamped to obtain a fusion decision vector; Based on the factory power consumption limit and the temperature value and temperature rise rate value in the fusion decision vector, a hardware safe power consumption limit is generated; Based on the utilization rate and business priority in the fusion decision vector, a performance requirement power consumption limit is generated; A dynamic power consumption wall is generated based on the hardware security power consumption limit, the performance requirement power consumption limit, and the factory power consumption wall. Based on the actual power consumption and the dynamic power limit, the target processor is subjected to frequency reduction processing to obtain the actual power consumption after frequency reduction. In response to the detection that the actual power consumption after frequency reduction meets the preset jitter condition, frequency recovery processing is performed on the target processor to obtain the restored normal frequency.

2. The method according to claim 1, characterized in that, The step of generating a hardware safety power consumption limit based on the factory power consumption limit and the temperature value and temperature rise rate value in the fusion decision vector includes: A temperature coefficient is generated based on the temperature value and a preset temperature mapping relationship; A temperature rise rate coefficient is generated based on the temperature rise rate value and the preset temperature rise rate mapping relationship; The safety factor is determined based on the temperature coefficient and the temperature rise rate coefficient. The product of the factory power consumption limit and the security factor is determined as the upper limit of hardware safe power consumption.

3. The method according to claim 1, characterized in that, The step of generating the upper limit of performance requirement power consumption based on the utilization and service priority in the fusion decision vector includes: Based on the aforementioned business priorities, a target priority coefficient is generated; The product of the factory power consumption limit, the utilization rate, and the priority coefficient is determined as the upper limit of the power consumption required for performance.

4. The method according to claim 1, characterized in that, The step of generating a dynamic power consumption wall based on the hardware security power consumption limit, the performance requirement power consumption limit, and the factory power consumption wall includes: The target power consumption value is determined based on the hardware security power consumption limit, the performance requirement power consumption limit, and the factory power consumption limit. The target power consumption value is determined as the dynamic power consumption wall.

5. The method according to claim 1, characterized in that, The step of performing frequency down-regulation on the target processor based on the actual power consumption and the dynamic power limit to obtain the actual power consumption after frequency reduction includes: In response to determining that the actual power consumption is greater than or equal to a first value and less than the dynamic power limit, a slight frequency reduction is determined as the target frequency reduction level; In response to determining that the actual power consumption is greater than or equal to the dynamic power limit, a moderate frequency reduction is determined as the target frequency reduction level; Based on the target frequency reduction level, the target processor is subjected to frequency reduction processing to obtain the actual power consumption after frequency reduction.

Images