CN114503055A

CN114503055A - Power management method and apparatus

Info

Publication number: CN114503055A
Application number: CN201980099695.4A
Authority: CN
Inventors: 宋军; 靳玲玲; 程霖; 卢毅军; 奉有泉; 孟晓林; 朱昊
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2019-09-27
Filing date: 2019-09-27
Publication date: 2022-05-13
Also published as: WO2021056417A1

Abstract

Methods and apparatus for improved power management are provided. A power management component receives a power capping command for a computing system. The computing system includes a plurality of processing components. The computing system includes a plurality of power domains distributed among a plurality of processing components. The power management component merges one or more instances running on a first set of power domains onto a second set of power domains. The power management component performs power capping on the plurality of power domains in the computing system excluding the second set of power domains.

Description

Power management method and apparatus

Technical Field

The present disclosure relates to the field of power management, and more particularly, to methods and apparatus for power management of computing systems.

Background

Power capping is a technique widely used in modern Data Centers (DC) to increase server deployment density on racks and avoid blackouts. However, during power capping supported by vendor-provided hardware and firmware, the performance of different types of processing components (e.g., CPU and GPU) is consistently degraded due to power capping. Thus, the performance of high priority instances/applications may be negatively impacted during power capping.

Typically, CPU manufacturers and GPU manufacturers provide power capping capabilities to CPUs and GPUs. However, the power capping control logic provided by the manufacturer simply throttles the power consumption of the entire system until the power capping target is reached. However, the manufacturer does not consider that performance-critical instances/applications running on the system are affected due to power capping.

Currently, GPU servers are expensive and performance-critical instances/applications such as AI training and reasoning jobs running thereon are important. Thus, cloud service providers do not want performance degradation of GPU servers. On the other hand, the GPU server is high in power consumption. For example, the Thermal Design Power (TDP) rating of an 8-card GPU server may be 3000W. The high TDP makes it difficult to fit GPU servers into power compact racks without increasing the risk of tripping. Therefore, power capping is necessary from the perspective of cost optimization of the Total Cost of Ownership (TCO) of the Internet Data Center (IDC). Thus, a dilemma arises-performance-critical instances/applications run by the GPU server cannot be slowed down, yet IDC requires the use of power capping to reduce cost and avoid tripping risks.

Accordingly, it is desirable to perform power capping on computing systems without significantly compromising performance-critical instances/applications.

Disclosure of Invention

This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in limiting the scope of the claimed subject matter.

Example implementations of power management methods and apparatus are described below. In an implementation, a power management component receives a power capping command for a computing system. The computing system includes a plurality of processing components. The computing system includes a plurality of power domains distributed among a plurality of processing components. The power management component merges one or more instances running on a first set of power domains onto a second set of power domains. The power management component performs power capping differently based on the type of power domain. The second set of power domains are significant power domains, whereas the other power domains are non-significant power domains. In an implementation, the power management component performs power capping for non-critical power domains and not critical power domains. Additionally or alternatively, the power management component performs a first power capping process on the non-essential power domains and performs a second power capping process on the essential power domains, wherein the second power capping process has less impact on the performance of the essential power domains than the first power capping process has on the performance of the non-essential power domains.

After consolidation, the power consumption of the important and non-important power domains may be managed differently. During power capping, the performance of the important power domains on which the performance-important instances/applications run may not experience degradation or degrade less than the non-important power domains. Because performance of the critical power domain is guaranteed, the impact of power capping on the overall performance of the computing system can be reduced. Thus, the performance impact during power capping is mitigated.

Drawings

The detailed description is set forth with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference symbols in different drawings indicates similar or identical items or features.

FIG. 1A illustrates an example block diagram of a computing system.

FIG. 1B illustrates an example block diagram of a computing system after merging/combining.

FIG. 2 illustrates an example flow diagram of a process for merging/combining performance important instances/applications in a computing system.

FIG. 3A illustrates an example block diagram of a computing system in an initial state.

Fig. 3B illustrates an example block diagram of a computing system after merging/combining.

Fig. 4 illustrates an example flow diagram of a process for merging/combining performance-critical instances/applications and performing power capping based on critical and non-critical power domains.

FIG. 5 illustrates an example block diagram of a computing system in communication with a global scheduler.

FIG. 6 illustrates an example system for implementing the above-described processes and methods.

Detailed Description

The terms used herein are expressed as follows. Power capping refers to limiting the power consumption of a system, component, resource, etc. to not exceed an upper power limit. The upper power limit refers to a power limit that the power consumption of a system, component, resource, etc. cannot exceed. A scheduler refers to a central or distributed controller that allocates and migrates instances. An instance/application refers to a process, Virtual Machine (VM), container, job, thread, etc.

Fig. 1A illustrates an example block diagram of a computing system 100. The computing system 100 is implemented in a distributed system.

Referring to FIG. 1A, computing system 100 includes different types of processing components, such as M CPUs and P GPUs, where M and P are positive integers. The M CPUs include CPU slot _0102, … CPU slot _ M-1104. The P GPUs include GPU _ 0106, …, GPU _ P-1108. The respective CPU or GPU comprises one or more power domains, the power consumption of which can be controlled individually. The respective power domain includes one or more core and/or non-core slices. For example, CPU slot _0102 includes N power domains, namely Power Domain _ 0110, Power Domain _ 1112, …, Power Domain _ N-1114, where N is a positive integer. CPU socket _ M-1104 includes N power domains, namely power domain _ 0116, power domain _ 1118. GPU _ 0106 includes Q power domains, namely power domain _ 0122, power domain _ 1124, and power domain _ Q-1126, where Q is a positive integer. GPU _ 1108 includes Q power domains, namely power domain _ 0128, power domain _ 1130, …, power domain _ Q-1132.

There may be different types of power domains. For example, the power domain may be a critical power domain or a non-critical power domain. An important power domain is a power domain on which one or more performance-important instances/applications run. The power budget of the important power domains should not be reduced during power capping and the important power domains do not run at lower speeds due to power capping. A non-critical power domain is a power domain on which a performance critical instance/application does not run. The power budget of the non-essential power domains can be reduced during power capping and the non-essential power domains can run at a lower speed due to power capping.

In an implementation, a performance-critical instance/application is defined as an instance/application for which the performance of the resource running the instance/application is critical or has a significant impact. For example, an instance/application where performance is important is AI training or reasoning jobs. In an implementation, the performance important instance may be a latency sensitive instance. Delay sensitive examples require a delay below a first threshold, e.g., 10 mus, 5 mus, etc. Additionally or alternatively, the performance important instance may be a throughput sensitive instance. Throughput-sensitive examples require an instruction execution rate that is higher than a second threshold, such as 200 ten thousand instructions per second, 500 ten thousand instructions per second, and so on. The first and second thresholds may be dynamically set and/or adjusted based on actual needs.

As an example, FIG. 1A shows 4 important power domains, namely, power domain _ 1112 in CPU slot _0102, power domain _ 0116 in CPU slot _ M-1104, power domain _ 0122 in GPU _ 0106, and power domain _ Q-1132 in GPU _ P-1108. The other power domains are non-significant power domains. The important power domains are shown in dashed boxes, whereas the non-important power domains are shown in solid boxes.

FIG. 1B illustrates an example block diagram of the computing system 100' after consolidation/combining, with the important power domains shown in dashed boxes, while the non-important power domains are shown in solid boxes.

Referring to FIG. 1B, all CPU performance critical instances/applications are merged/combined onto Power Domain _ 0110 and Power Domain _ 1112 in CPU slot _0102, and all GPU performance critical instances/applications are merged/combined onto Power Domain _ 0122 and Power Domain _ 1124 in GPU _ 0106. The other power domains are non-significant power domains. Prior to merging/combining, the critical power domains are distributed among 2 CPU slots and 2 GPUs. After merging/combining, the important power domains are distributed in 1 CPU socket and 1 GPU. Thus, all performance-critical instances/applications are merged/combined onto a smaller number of processing components (CPU slots or GPUs).

As described above with reference to fig. 1A and 1B, power capping can be divided among different types of processing components (e.g., CPU and GPU) to ensure performance of performance-critical instances/applications. The merging/combining of instances/applications can facilitate power savings and result in less performance loss for non-critical power domains.

In implementations, when power capping occurs, power capping can be performed differently based on the type of power domain. For example, the power consumption of the critical power domains is not capped/limited, whereas the power consumption of the non-critical power domains is capped/limited. Additionally or alternatively, the power consumption of the critical power domains is capped/limited relatively slightly, whereas the power consumption of the non-critical power domains is capped/limited relatively deeply. Processing components such as CPU slot _ M-1104 and GPU _ P-1108 of FIG. 1B, which include only non-critical power domains, are better able to stay in the deep idle state and absorb power outages to achieve the power capping goals of the overall computing system. Because the power consumption of the important power domains is not capped/limited or is capped/limited relatively slightly, the performance of the important power domains may not experience degradation or degrade less than the non-important power domains, thus enabling the performance of the important power domains to be guaranteed. Because no performance-critical instances/applications are running on the non-critical power domains, the performance penalty for the non-critical power domains can be mitigated. During power capping, non-critical power domains may experience less pain. Thus, power management during power capping is improved.

Additionally or alternatively, the number of GPU servers placed on the rack can be reduced. Additionally or alternatively, a mix of GPU servers and CPU servers on the rack may be avoided. Additionally or alternatively, a dedicated power supply may be provided for the GPU server.

Although in fig. 1A and 1B, computing system 100 (100') includes two types of processing components, namely a CPU and a GPU, the computing system may include other types of processing components, such as Field Programmable Gate Arrays (FPGAs), application specific integrated circuits ("ASICs"), Digital Signal Processors (DSPs), and so forth.

Fig. 2 illustrates an example flow diagram of a process 200 for merging/combining performance-important instances/applications in a computing system.

In block 202, the power management component receives a power capping command for the computing system. The computing system includes a plurality of processing components. A respective processing component of the plurality of components includes a plurality of power domains. The power capping command of the computing system includes a power capping target of the computing system.

In an implementation, a power management component is a component that monitors and manages power consumption of a computing system. The power management component may be implemented in software, hardware, firmware, or any combination thereof. The power management component performs a power capping process on the computing system such that the power consumption of the computing system does not exceed the power limit/upper bound. The power limit/upper limit may be dynamically set and/or adjusted based on actual needs.

In an implementation, a first set of power domains is distributed among a first number of processing components. The second set of power domains is distributed among a second number of processing components. The second number is smaller than the first number.

In an implementation, the plurality of processing components includes a plurality of Central Processing Units (CPUs) and/or a plurality of Graphics Processing Units (GPUs).

In an implementation, the upper power limits of respective ones of the plurality of power domains are individually controlled.

In block 204, the power management component merges/combines one or more instances running on the first set of power domains onto the second set of power domains.

In an implementation, a power management component checks one or more merge rules, determines that one or more instances are allowed to merge based on the one or more merge rules, and merges the one or more instances running on a first set of power domains onto a second set of power domains.

In implementations, one or more merge rules may be configured based on the priority level of an instance/application, which may be determined based on customer requirements. In some embodiments, relatively high priority instances/applications are not allowed to be merged/combined, and relatively low priority instances/applications are allowed to be merged/combined. As an example, there are high priority instances/applications and low priority instances/applications running simultaneously on the power domain. The merge rule may allow merging of low priority instances/applications onto another power domain so that high priority instances/applications may dominate the resource usage so that the requirements of high priority clients can be ensured. Additionally or alternatively, one or more merge rules may be configured by the service provider based on factors such as load characteristics, cost control, and the like. One or more merge rules may be dynamically configured and/or adjusted.

Additionally or alternatively, the power management component communicates with and receives information from the scheduler. The power management component determines that the set of instances is allowed to merge based on information from the scheduler and merges one or more instances running on the first set of power domains onto the second set of power domains.

In an implementation, the one or more instances are one or more performance-critical instances. A performance critical instance/application is defined as an instance/application for which the performance of the resource running the instance/application is critical to the instance/application. For example, an example/application where performance is important is an Artificial Intelligence (AI) training job. In an implementation, one or more performance-critical instances require a latency below a first threshold. Additionally or alternatively, one or more performance-critical instances require an instruction execution rate above a second threshold. The first and second thresholds may be dynamically set and/or adjusted based on actual needs.

In block 206, the power management component performs power capping for a plurality of power domains in the computing system that excludes the second set of power domains.

In an implementation, a power management component sets respective upper power limits for respective ones of a plurality of power domains in the computing system excluding a second set of power domains. The power management component performs power capping on respective ones of a plurality of power domains in the computing system excluding the second set of power domains based on the respective upper power limits.

In block 208, the power management component performs a first power capping process for the plurality of power domains excluding the second set of power domains and performs a second power capping process for the second set of power domains.

In an implementation, the power management component sets a respective upper power limit for the respective critical power domain and sets a respective upper power limit for the respective non-critical power domain. The impact of the upper power limit on the performance of the important power domain may be less than the impact of the upper power limit on the performance of the non-important power domain. The upper power limit for the non-essential power domains may significantly reduce the power consumption of the non-essential power domains. The respective upper power limit may be dynamically set and/or adjusted based on actual needs. The power management component performs a first power capping procedure for a plurality of power domains excluding a second set of power domains and performs a second power capping procedure for the second set of power domains based on an upper power limit. The impact of the second power capping process on the performance of the second set of power domains may be less than the impact of the first power capping process on the performance of the plurality of power domains excluding the second set of power domains.

In an implementation, the first power capping process may include a number of power capping sub-modes that may be applied to the important power domains based on priorities of instances/applications running on the important power domains. For example, a VIP customer may have a high demand service and instances/applications of a first priority level. The first power capping sub-mode may be performed on important power domains running instances/applications having a first priority level such that performance of such important power domains is not affected during power capping. For example, a relatively low priority customer may have a relatively lower demand service and have instances/applications of a second priority level. The second power capping sub-mode may be performed on important power domains running instances/applications of the second priority level such that performance of such important power domains is not significantly degraded during power capping. The power capping submode may be dynamically configured and/or adjusted based on actual needs.

In an implementation, the second power capping process may include a number of power capping sub-modes that may be applied to the non-essential power domains based on a priority level of instances/applications running on the non-essential power domains. For example, a customer may have an instance/application with a third level of priority. The third power capping sub-mode may be performed on non-essential power domains running instances/applications with a third priority level such that the performance of such non-essential power domains is significantly reduced to accommodate power capping. For example, another customer may have an instance/application with a fourth priority level. The fourth power capping sub-mode may be performed on non-critical power domains running instances/applications of the fourth priority level such that the power consumption of such non-critical power domains is reduced as much as possible to absorb the outage. The power capping submode may be dynamically configured and/or adjusted based on actual needs.

In an implementation, the power capping process/sub-mode may be performed based on a customer's selection. For example, a customer with a fourth priority level may be dissatisfied with the service. The service provider may offer different priority level selections to the customer. The client may upgrade his/her priority level with the option. In that case, a higher level power capping process/sub-mode may be performed on the power domain running the customer's instance/application after the update. The customer may experience a higher level of service. The priority level may be dynamically set and/or adjusted.

Using the example process 200 described above, the power management component merges/combines performance-important instances/applications onto fewer processing components. Power capping can be performed differently for critical and non-critical power domains such that the impact of power capping on the performance of the critical power domains is less than the impact of power capping on the performance of the non-critical power domains. Processing components that include only non-critical power domains can have better opportunities to stay in deep idle states and absorb power outages to achieve power capping goals for the entire computing system. Because the power consumption of the important power domains is not capped/limited or capped/limited relatively slightly, the performance of the important power domains may not experience significant degradation. Thus, power management during power capping is improved.

Fig. 3A illustrates an example block diagram of a computing system 300 in an initial state. The initial state refers to the state of the computing system that does not perform power capping.

Referring to FIG. 3A, computing system 300 includes CPU slot _ 0302, CPU slot _ 1304, GPU _ 0306, and GPU _ 1308. CPU slot _ 0302 includes the following power domains, core _ 0-3310, core _ 4-7312, non-core slice # 0314, core _ 8-27316, and non-core slice # 1318. CPU slot _ 1304 includes the following power domains, core _ 0-3320, core _ 4-7322, non-core slice #0324, core _ 8-27326, and non-core slice # 1328. GPU _ 0306 includes the following power domains, core _ 0-511330, core _ 512-1023332, and core _ 1024-4095334. GPU _ 1308 includes the following power domains, core _ 0-511336, core _ 512-1023338, and core _ 1024-4095340.

Because computing system 300 is in an initial state where power capping is not performed, power consumption per power domain is not limited/capped. For example, in CPU slot _ 0302, core _ 0-3310 consumes 5W of power; core _ 4-7312 consumes 5W of power; non-core slice # 0314 consumes 7W of power; core _ 8-27316 consumes 28W of power; and non-core slice # 1318 consumes 7W of power. In CPU socket _ 1304, core _ 0-3320 consumes 5W of power; core _ 4-7322 consumes 5W of power; non-core slice #0324 consumes 7W of power; core _ 8-27326 consumes 28W of power; and non-core slice # 1328 consumes 7W of power. Core _ 0-511330 consumes 25W of power in GPU _ 0306; core _ 512-1023332 consumes 25W of power; and core 1024-. In GPU _ 1308, cores _ 0-511336 consume 25W of power; core _ 512-1023338 consumes 25W of power; and core 1024-.

Because power capping does not occur, the power budget for each power domain is not limited, and thus the performance of each power domain (core and/or non-core slices) is not degraded or degraded. The dashed boxes 310-340 indicate that these power domains are important power domains that consume power.

Fig. 3B illustrates an example block diagram of the computing system 300' after merging/combining. The important power domains are shown in dashed boxes, while the non-important power domains are shown in solid boxes.

Referring to FIG. 3B, after merging/combining, all CPU performance critical instances/applications are merged/combined on core _ 0-3310, core _ 4-7312, and non-core slice # 0314 in CPU slot _302, and all GPU performance critical instances/applications are merged/combined on core _ 0-511330 and core _512 and 1023332 in GPU _ 0306.

As an example, in CPU slot _ 0302, cores _ 0-3310 consume 5W of power, which is the same power consumption before merging/combining. Core _ 4-7312 consumes 5W of power, which is the same power consumption prior to merging/combining. Non-core slice # 0314 consumes 7W of power, which is the same power consumption before merging/combining. Core _ 8-27316 consumes 18W of power, which is lower than the power consumption of 28W before merging/combining. Uncore slice # 1318 consumes 5W of power, which is lower than the power consumption of 7W before merging/combining.

In CPU socket _ 1304, cores _ 0-3320 consume 4W of power, which is lower than the power consumption of 5W before merging/combining. Core _ 4-7322 consumes 4W of power, which is lower than the power consumption of 5W before merging/combining. Non-core slice #0324 consumes 5W of power, which is lower than the power consumption of 7W before merging/combining. Core _ 8-27326 consumes 18W of power, which is lower than the power consumption of 28W before merging/combining. Uncore slice # 1328 consumes 5W of power, which is lower than the power consumption of 7W before merging/combining.

In GPU _ 0306, cores _ 0-511330 consume 25W of power, which is the same power consumption as before merging/combining. Core 512-1023332 consumes 25W of power, which is the same power consumption prior to merging/combining. Core 1024-.

In GPU _ 1308, cores _ 0-511336 consume 15W of power, which is lower than the power consumption of 25W prior to merging/combining. Core 512 1023338 consumes 15W of power, which is lower than the 25W power consumption before merging/combining. Core 1024-.

Although in fig. 3A and 3B, computing system 300 (300') includes two types of processing components, namely a CPU and a GPU, computing systems may include other types of processing components, such as Field Programmable Gate Arrays (FPGAs), application specific integrated circuits ("ASICs"), Digital Signal Processors (DSPs), and so forth.

In the above example, power capping is performed based on the important power domain and the non-important power domain. After merging/combining, when power capping occurs, the power consumption of the important power domains is not affected, whereas the power consumption of the non-important power domains is reduced. Performance of important instances/applications the performance of important power domains on which they run is not affected by power capping. Due to power capping, some level of performance degradation may occur in the non-critical power domains. Because performance of the critical power domain is guaranteed, the impact of power capping on the overall performance of the computing system can be limited. Thus, power management during power capping is improved.

Additionally or alternatively, the power consumption of the critical power domains may be capped/limited relatively slightly and the power consumption of the non-critical power domains may be reduced relatively deeply. In that case, the performance of the critical power domains may experience less degradation than the non-critical power domains, and the non-critical power domains may stay in an idle state to absorb the power outage to achieve the power capping goals for the entire computing system.

Fig. 4 illustrates an example flow diagram of a process 400 for merging/combining performance-critical instances/applications and performing power capping based on critical and non-critical power domains.

In block 402, the power management component receives a power capping command for the computing system. The power capping command includes a power capping target of the computing system. The power capping target can be set/adjusted dynamically based on actual needs. A power management component is a component that monitors and manages the power consumption of a computing system. The power management component can be implemented in software, hardware, firmware, or any combination thereof.

In block 404, the power management component identifies performance important instances/applications running on the computing system.

In an implementation, the power management component traverses the PROC TREE of the computing system to identify all performance-important instances/applications running on the computing system.

In block 406, the power management component marks the power domain on which the performance-critical instance/application is running as the critical power domain. For example, the power management component labels X power domains as important power domains, where X is a positive integer.

In block 408, the power management component checks one or more merge rules or communicates with the scheduler.

In an implementation, one or more merge rules regulate whether instances/applications are allowed to merge/combine.

In an implementation, a power management component communicates with a scheduler and receives information from the scheduler indicating whether instances/applications are allowed to be merged/combined.

In implementations, a scheduler is responsible for allocating and migrating instances/applications in a computing environment. The scheduler maintains information for each instance/application as to whether the instance/application is important and whether the instance/application is allowed to merge/combine, which can be determined based on a Service Level Agreement (SLA) between the service provider and the customer. The scheduler can communicate with the power management component using native or virtualized communication methods to send information to the power management component. In an implementation, the scheduler may be a global scheduler or a local scheduler. More details of the global scheduler and the local scheduler are illustrated in fig. 5.

In block 410, the power management component determines whether the performance important instances/applications are allowed to merge/combine.

In an implementation, the power management component determines whether performance-critical instances/applications are allowed to merge/combine based on one or more merge rules. In implementations, one or more merge rules may be configured based on the priority level of an instance/application, which may be determined based on customer requirements. In some embodiments, relatively high priority instances/applications are not allowed to be merged/combined, and relatively low priority instances/applications are allowed to be merged/combined. As an example, there are high priority instances/applications and low priority instances/applications running simultaneously on the power domain. The merge rule may allow merging of low priority instances/applications onto another power domain so that high priority instances/applications may dominate the resource usage so that the requirements of high priority clients can be ensured. Additionally or alternatively, one or more merge rules may be configured by the service provider based on factors such as load characteristics, cost control, and the like. One or more merge rules may be dynamically configured and/or adjusted.

In an implementation, the power management component may determine whether performance-important instances/applications are allowed to merge/combine based on information from the scheduler.

If the power management component determines at block 410 that the instances/applications are allowed to be merged/combined, the power management component merges/combines the instances/applications at block 412.

In an implementation, the power management component merges/combines performance-important instances/applications running on X power domains onto Y power domains, where Y is a positive integer and Y < ═ X.

In an implementation, the power management component merges/combines performance-important instances/applications onto fewer processing components. For example, prior to combining/combining, X significant power domains are distributed among i processing components, where i is a positive integer. After combining/combining, the Y significant power domains are distributed among the j processing components, where j is a positive integer, and i > j. Thus, performance-critical instances/applications are merged/combined onto fewer processing components.

After the power management component merges the instances/applications at block 412, the power management component updates and marks the new important power domain at block 414.

In an implementation, after merging/combining performance-critical instances running on X critical power domains onto Y critical power domains, the Y critical power domains are labeled as critical power domains.

If the power management component determines at block 410 or after block 414 that the performance important instance/application is not allowed to merge/combine, the power management component sets an upper power limit based on the type of power domain at block 416.

In an implementation, the power management component may set a power cap for the non-critical power domain instead of setting a power cap for the critical power domain.

Additionally or alternatively, the power management component may set a respective upper power limit for the respective important power domain and a respective upper power limit for the respective non-important power domain. The respective upper power limits may be dynamically set and/or adjusted based on actual needs. The upper power limit for the non-essential power domains may significantly reduce the power consumption of the non-essential power domains.

In block 418, the power management component performs power capping based on the type of power domain.

In an implementation, the power management component begins adjusting the upper power limit for the non-critical power domains without performing power capping on the critical power domains. In that case, the power consumption of the critical power domains is not capped/limited, whereas the power consumption of the non-critical power domains is capped/limited. Thus, the performance of the important power domains is not degraded by power capping. Non-critical power domains may have a better chance of staying in a deep idle state to absorb power outages to achieve power capping goals for the entire computing system.

Additionally or alternatively, the power management component may perform a first power capping procedure for the critical power domains based on the upper power limit set at block 416 and perform a second power capping procedure for the non-critical power domains based on the upper power limit set at block 416. The impact of the second power capping process on the performance of the important power domains may be less than the impact of the first power capping process on the performance of the non-important power domains.

In an implementation, the first power capping process may include a number of power capping sub-modes that may be applied to the important power domains based on priority levels of instances/applications running on the important power domains. For example, a VIP customer may have a high demand service and instances/applications of a first priority level. The first power capping sub-mode may be performed on important power domains running instances/applications having a first priority level such that performance of such important power domains is not affected during power capping. For example, a relatively low priority customer may have a relatively lower demand service and have instances/applications of a second priority level. The second power capping sub-mode may be performed on important power domains running instances/applications of the second priority level such that performance of such important power domains is not significantly degraded during power capping. The power capping submode may be dynamically configured and/or adjusted based on actual needs.

In an implementation, the second power capping process may include a number of power capping sub-modes that may be applied to the non-essential power domains based on a priority level of instances/applications running on the non-essential power domains. For example, a customer may have an instance/application with a third level of priority. The third power capping sub-mode may be performed on non-essential power domains running instances/applications with a third priority level such that the performance of such non-essential power domains is significantly reduced to accommodate power capping. For example, another customer may have an instance/application with a fourth priority level. The fourth power capping sub-mode may be performed on non-critical power domains running instances/applications of the fourth priority level such that power consumption of such non-critical power domains is reduced as much as possible to absorb power outages. The power capping submode may be dynamically configured and/or adjusted based on actual needs.

In an implementation, the power capping process/sub-mode may be performed at the customer's option. For example, a customer with a fourth priority level may be dissatisfied with the service. The service provider may offer different priority level selections to the customer. The client may upgrade his/her priority level with the option. In that case, a higher level power capping process/sub-mode may be performed on the power domain running the customer's instance/application after the update. The customer may experience a higher level of service. The priority level may be dynamically set and/or adjusted.

With the example process 400, the power management component merges/combines performance-critical instances/applications onto fewer processing components. Power capping is performed differently for critical and non-critical power domains. Processing components that include only non-critical power domains can have better opportunities to stay in deep idle states and absorb power outages to achieve power capping goals for the entire computing system. Performance of the important power domains is guaranteed because their power consumption is not capped/limited or is capped/limited relatively slightly. Thus, power management during power capping is improved.

FIG. 5 illustrates an example block diagram that shows a computing system 500 in communication with a global scheduler 502.

Referring to FIG. 5, a computing system 500 communicates with a global scheduler 502. Computing system 500 includes a power management component 504 and a local scheduler 506. The power management component 504 communicates with a local scheduler 506.

In an implementation, the global scheduler 502 is a central controller that allocates and migrates instances/applications between the computing system 500 and other computing systems (not shown). The global scheduler 502 maintains information for each instance/application running under control on all computing systems as to whether the instance/application is important and whether the instance/application is allowed to merge/combine, which can be determined based on the SLA between the service provider and the customer. The global scheduler 502 communicates with the computing system 500 using native or virtualized communication methods to send information.

In an implementation, power management component 504 is a component that monitors and manages power consumption of computing system 500.

In an implementation, the local scheduler 506 is a distributed controller that distributes and migrates instances/applications within the computing system 500. The local scheduler 506 maintains information for each instance/application running on the computing system as to whether the instance/application is important and whether the instance/application is allowed to merge/combine, which can be determined based on the SLA between the service provider and the customer. The global scheduler 502 communicates with the power management component 504 using native or virtualized communication methods to send information to the power management component 504.

FIG. 6 illustrates an example system 600 for implementing the processes and methods described above.

The device 600 includes one or more processors 602 and memory 604 communicatively coupled to the processors 602. Processor 602 executes one or more modules and/or processes to cause processor 602 to perform various functions. Additionally, each processor 602 may have its own local memory, which may also store program modules, program data, and/or one or more operating systems. In an implementation, the memory 604 may be volatile, such as RAM, non-volatile, such as ROM, flash memory, a miniature hard drive, a memory card, etc., or some combination thereof.

Device 600 may additionally include an input/output (I/O) interface 606 for receiving and outputting data. The apparatus 600 may also include a communication module 608 that allows the apparatus 600 to communicate with other devices (not shown) over a network (not shown). The network may include the internet, wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, Radio Frequency (RF), infrared and other wireless media.

Memory 604 may include one or more computer-executable modules (modules) that may be executed by processor 602. In an implementation, the memory 604 may include, but is not limited to, a receive module 610, a merge module 612, and a power capping module 614.

The receiving module 610 is configured to receive a power capping command of a computing system. The computing system includes a plurality of processing components. The computing system includes a plurality of power domains distributed among a plurality of processing components.

The merge module 612 is configured to merge one or more instances running on the first set of power domains onto the second set of power domains.

The merge module 612 is further configured to check one or more merge rules, determine that one or more instances are allowed to merge based on the one or more merge rules, and merge one or more instances running on the first set of power domains onto the second set of power domains.

In implementations, one or more merge rules may be configured based on the priority level of an instance/application, which may be determined based on customer requirements. In some embodiments, relatively high priority instances/applications are not allowed to be merged/combined, and relatively low priority instances/applications are allowed to be merged/combined. As an example, there are high priority instances/applications and low priority instances/applications running simultaneously on the power domain. The merge rule may allow merging of low priority instances/applications onto another power domain so that high priority instances/applications may dominate the resource usage so that the requirements of high priority clients can be ensured. Additionally or alternatively, one or more consolidation rules may be configured by the service provider based on factors such as load characteristics, cost control, and the like. One or more merge rules may be dynamically configured and/or adjusted.

The merge module 612 is further configured to communicate with the scheduler, receive information from the scheduler, determine that one or more instances are allowed to merge based on the information from the scheduler, and merge one or more instances running on the first set of power domains onto the second set of power domains. In an implementation, the scheduler may be a global scheduler or a local scheduler.

In an implementation, the plurality of processing components includes a plurality of CPUs and/or a plurality of GPUs.

In an implementation, the one or more instances include one or more performance-critical instances. An example where performance is important may be a delay sensitive example. Delay sensitive examples require a delay below a first threshold, e.g., 10 mus, 5 mus, etc. Additionally or alternatively, the performance important instance may be a throughput sensitive instance. Throughput-sensitive examples require an instruction execution rate that is higher than a second threshold, such as 200 ten thousand instructions per second, 500 ten thousand instructions per second, and so on. The first and second thresholds may be dynamically set and/or adjusted based on actual needs.

The power capping module 614 is configured to perform power capping on a plurality of power domains in the computing system that excludes the second set of power domains.

The power capping module 614 is further configured to set respective upper power limits for respective ones of a plurality of power domains in the computing system that exclude the second set of power domains, and perform power capping on respective ones of the plurality of power domains in the computing system that exclude the second set of power domains based on the respective upper power limits.

Additionally or alternatively, the power capping module 614 is configured to perform power capping differently based on the type of power domain. The power capping module 614 may set a respective upper power limit for the respective critical power domain and a respective upper power limit for the respective non-critical power domain. The upper power limit for the non-essential power domains may significantly reduce the power consumption of the non-essential power domains. The power capping module 614 is further configured to perform a first power capping procedure for the plurality of power domains excluding the second set of power domains and perform a second power capping procedure for the second set of power domains. The impact of the second power capping process on the performance of the important power domains is less than the impact of the first power capping process on the performance of the non-important power domains.

In an implementation, the power capping process/sub-mode may be performed based on a customer's selection. For example, a customer with a fourth priority level may be dissatisfied with the service. The service provider may offer different priority level selections to the customer. The client may upgrade his/her priority level with the option. In that case, a higher level power capping process/sub-mode may be performed on the power domain running the customer's instance/application after the update. The customer may experience a higher level of service. The priority may be dynamically set and/or adjusted.

With the example apparatus 600 described above, the power management component merges/combines performance-critical instances/applications onto fewer processing components. Power capping is performed differently for critical and non-critical power domains. Processing components that include only non-critical power domains may have a better chance of staying in a deep idle state and absorb power outages to achieve power capping goals for the entire computing system. Performance of the important power domains is guaranteed because their power consumption is not capped/limited or is capped/limited relatively slightly. Thus, power management during power capping is improved.

The processes and systems discussed herein may be implemented in, but are not limited to, distributed computing environments, parallel computing environments, clustered computing environments, grid computing environments, cloud computing environments, electric vehicles, power facilities, and the like.

Some or all of the operations of the above-described methods can be performed by executing computer readable instructions stored on a computer readable storage medium as defined below. The term "computer readable instructions" as used in the specification and claims includes routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can be implemented on various system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, microprocessor-based, programmable consumer electronics, combinations thereof, and the like.

Computer-readable storage media include volatile memory (such as Random Access Memory (RAM)) and/or nonvolatile memory (such as Read Only Memory (ROM), flash memory, etc.). Computer-readable storage media may also include additional removable and/or non-removable storage devices, including, but not limited to, flash memory, magnetic storage, optical storage, and/or tape storage devices, which may provide non-volatile storage of computer-readable instructions, data structures, program modules, and the like.

Non-transitory computer-readable storage media are examples of computer-readable media. Computer-readable media includes at least two types of computer-readable media, namely computer-readable storage media and communication media. Computer-readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any process or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism. As defined herein, computer-readable storage media does not include communication media.

The computer-readable instructions stored on the one or more non-transitory computer-readable storage media, when executed by the one or more processors, may perform the operations described above with reference to fig. 1-6. Generally, computer readable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.

Example clauses

Clause 1. a method, comprising: receiving a power capping command for a computing system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components; merging one or more instances running on the first set of power domains onto the second set of power domains; and performing power capping on the plurality of power domains in the computing system excluding the second set of power domains.

Clause 2. the method of clause 1, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

Clause 3. the method of clause 1, wherein the upper power limits of the respective ones of the plurality of power domains are individually controlled.

Clause 4. the method of clause 1, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises: checking one or more merge rules; determining that the one or more instances are allowed to be merged based on the one or more merging rules; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 5. the method of clause 1, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises: communicating with a scheduler; receiving information from the scheduler; determining that the one or more instances are allowed to merge based on the information from the scheduler; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 6. the method of clause 1, wherein performing power capping on the plurality of power domains in the computing system excluding the second set of power domains comprises: setting respective upper power limits for respective ones of the plurality of power domains in the computing system excluding the second set of power domains; and performing power capping on the respective power domain of the plurality of power domains in the computing system excluding the second set of power domains based on the respective upper power limit.

Clause 7. the method of clause 1, wherein the one or more instances comprise one or more performance important instances.

Clause 8. the method of clause 7, wherein the one or more instances where performance is important require a latency below a first threshold.

Clause 9. the method of clause 7, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

Clause 10. a computer-readable storage medium storing computer-readable instructions executable by one or more processors, which, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving a computed power capping command system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components; merging one or more instances running on the first set of power domains onto the second set of power domains; and performing power capping on the plurality of power domains in the computing system excluding the second set of power domains.

Clause 11. the computer-readable storage medium of clause 11, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

Clause 12. the computer-readable storage medium of clause 10, wherein the plurality of processing components comprises a plurality of CPUs and/or a plurality of GPUs.

Clause 13. the computer-readable storage medium of clause 10, wherein the upper power limits of the respective ones of the plurality of power domains are individually controlled.

Clause 14. the computer-readable storage medium of clause 10, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises: checking one or more merge rules; determining that the one or more instances are allowed to be merged based on the one or more merging rules; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 15. the computer-readable storage medium of clause 10, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises: communicating with a scheduler; receiving information from the scheduler; determining that the one or more instances are allowed to merge based on the information from the scheduler; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 16 the computer-readable storage medium of clause 10, wherein performing power capping on the plurality of power domains in the computing system excluding the second set of power domains comprises: setting respective upper power limits for respective ones of the plurality of power domains in the computing system excluding the second set of power domains; and performing power capping on the respective power domain of the plurality of power domains in the computing system excluding the second set of power domains based on the respective upper power limit.

Clause 17. the computer-readable storage medium of clause 10, wherein the one or more instances comprise one or more performance important instances.

Clause 18. the computer-readable storage medium of clause 17, wherein the one or more instances of performance importance require a latency below a first threshold.

Clause 19. the computer-readable storage medium of clause 17, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

Clause 20. an apparatus, comprising: one or more processors; and a memory communicatively coupled to the one or more processors, the memory storing computer-executable modules executable by the one or more processors, the computer-executable modules comprising: a receiving module configured to receive a power capping command for a computing system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components; a merging module configured to merge one or more instances running on a first set of power domains onto a second set of power domains; and a power capping module configured to perform power capping on the plurality of power domains in the computing system excluding the second set of power domains.

Clause 21. the apparatus of clause 20, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

Clause 22. the apparatus of clause 20, wherein the upper power limits of the respective ones of the plurality of power domains are individually controlled.

Clause 23. the apparatus of clause 20, wherein the merge module is further configured to: checking one or more merge rules; determining that the one or more instances are allowed to be merged based on the one or more merging rules; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 24. the apparatus of clause 20, wherein the merge module is further configured to: communicating with a scheduler; receiving information from the scheduler; determining that the one or more instances are allowed to merge based on the information from the scheduler; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 25. the apparatus of clause 20, wherein the power capping module is further configured to: setting respective upper power limits for respective ones of the plurality of power domains in the computing system excluding the second set of power domains; and performing power capping on the respective power domain of the plurality of power domains in the computing system excluding the second set of power domains based on the respective upper power limit.

Clause 26. the apparatus of clause 20, wherein the one or more instances comprise one or more performance important instances.

Clause 27. the apparatus of clause 26, wherein the one or more instances where performance is important require a latency below a first threshold.

Clause 28. the apparatus of clause 26, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

Clause 29. a method, comprising: receiving a power capping command for a computing system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components; merging one or more instances running on the first set of power domains onto the second set of power domains; performing a first power capping process on the plurality of power domains excluding the second set of power domains; and performing a second power capping process on the second set of power domains.

Clause 30. the method of clause 29, wherein the impact of the second power capping process on the performance of the second set of power domains is less than the impact of the first power capping process on the performance of the plurality of power domains excluding the second set of power domains.

The method of claim 29, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

Clause 32. the method of clause 29, wherein the upper power limits of the respective ones of the plurality of power domains are individually controlled.

Clause 33. the method of clause 29, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises: checking one or more merge rules; determining that the one or more instances are allowed to be merged based on the one or more merging rules; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 34. the method of clause 29, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises: communicating with a scheduler; receiving information from the scheduler; determining that the one or more instances are allowed to merge based on the information from the scheduler; and merging the one or more instances running on the first set of power domains onto the second set of power domains.

Clause 35. the method of clause 29, wherein performing the first power capping process on the plurality of power domains excluding the second set of power domains comprises: setting respective upper power limits for respective ones of the plurality of power domains excluding the second set of power domains; and performing the first power capping procedure for the respective power domain based on the respective upper power limit.

Clause 36. the method of clause 29, wherein performing the second power capping process on the second set of power domains comprises: setting respective upper power limits for respective power domains of the second set of power domains; and performing the second power capping procedure for the respective power domain based on the respective upper power limit.

Clause 37. the method of clause 29, wherein the one or more instances comprise one or more performance important instances.

Clause 38. the method of clause 37, wherein the one or more instances where performance is important require a latency below a first threshold.

Clause 39. the method of clause 37, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

Conclusion

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. A method, the method comprising:

receiving a power capping command for a computing system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components;

merging one or more instances running on the first set of power domains onto the second set of power domains; and

performing power capping on the plurality of power domains in the computing system excluding the second set of power domains.

2. The method of claim 1, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

3. The method of claim 1, wherein the upper power limit of respective ones of the plurality of power domains is controlled individually.

4. The method of claim 1, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises:

checking one or more merge rules;

determining that the one or more instances are allowed to be merged based on the one or more merging rules; and

merging the one or more instances running on the first set of power domains onto the second set of power domains.

5. The method of claim 1, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises:

communicating with a scheduler;

receiving information from the scheduler;

determining that the one or more instances are allowed to merge based on the information from the scheduler; and

6. The method of claim 1, wherein performing power capping on the plurality of power domains in the computing system excluding the second set of power domains comprises:

setting respective upper power limits for respective ones of the plurality of power domains in the computing system excluding the second set of power domains; and

performing power capping on the respective ones of the plurality of power domains in the computing system excluding the second set of power domains based on the respective upper power limits.

7. The method of claim 1, wherein the one or more instances comprise one or more performance important instances.

8. The method of claim 7, wherein the one or more performance important instances require a latency below a first threshold.

9. The method of claim 7, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

10. A computer-readable storage medium storing computer-readable instructions executable by one or more processors, the computer-readable instructions, when executed by the one or more processors, causing the one or more processors to perform operations comprising:

receiving a computed power capping command system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components;

11. The computer-readable storage medium of claim 10, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

12. The computer-readable storage medium of claim 10, wherein the plurality of processing components comprises a plurality of CPUs and/or a plurality of GPUs.

13. The computer-readable storage medium of claim 10, wherein the upper power limits of respective ones of the plurality of power domains are individually controlled.

14. The computer-readable storage medium of claim 10, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises:

checking one or more merge rules;

15. The computer-readable storage medium of clause 10, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises:

communicating with a scheduler;

receiving information from the scheduler;

16. The computer-readable storage medium of claim 10, wherein performing power capping on the plurality of power domains in the computing system excluding the second set of power domains comprises:

17. The computer-readable storage medium of claim 10, wherein the one or more instances comprise one or more performance important instances.

18. The computer-readable storage medium of claim 17, wherein the one or more performance important instances require a latency below a first threshold.

19. The computer-readable storage medium of claim 17, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

20. An apparatus, the apparatus comprising:

one or more processors; and

a memory communicatively coupled to the one or more processors, the memory storing computer-executable modules executable by the one or more processors, the computer-executable modules comprising:

a receiving module configured to receive a power capping command for a computing system, the computing system comprising a plurality of processing components, the computing system comprising a plurality of power domains distributed among the plurality of processing components;

a merging module configured to merge one or more instances running on a first set of power domains onto a second set of power domains; and

a power capping module configured to perform power capping on the plurality of power domains in the computing system excluding the second set of power domains.

21. The apparatus of claim 20, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

22. The apparatus of claim 20, wherein the upper power limit of respective ones of the plurality of power domains is controlled individually.

23. The device of claim 20, wherein the merge module is further configured to:

checking one or more merge rules; determining that the one or more instances are allowed to be merged based on the one or more merging rules; and

24. The device of claim 20, wherein the merge module is further configured to:

communicating with a scheduler;

receiving information from the scheduler;

25. The apparatus of claim 20, wherein the power capping module is further configured to:

26. The apparatus of claim 20, wherein the one or more instances comprise one or more performance important instances.

27. The apparatus of claim 26, wherein the one or more performance important instances require a latency below a first threshold.

28. The apparatus of claim 26, wherein the one or more performance important instances require an instruction execution rate above a second threshold.

29. A method, the method comprising:

merging one or more instances running on the first set of power domains onto the second set of power domains;

performing a first power capping process on the plurality of power domains excluding the second set of power domains; and

performing a second power capping procedure on the second set of power domains.

30. The method of claim 29, wherein an impact of the second power capping process on performance of the second set of power domains is less than an impact of the first power capping process on performance of the plurality of power domains excluding the second set of power domains.

31. The method of claim 29, wherein the first set of power domains is distributed among a first number of processing components and the second set of power domains is distributed among a second number of processing components, and the second number is less than the first number.

32. The method of claim 29, wherein the upper power limit for respective ones of the plurality of power domains is controlled individually.

33. The method of claim 29, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises:

34. The method of claim 29, wherein merging the one or more instances running on the first set of power domains onto the second set of power domains comprises:

communicating with a scheduler;

receiving information from the scheduler;

35. The method of claim 29, wherein performing the first power capping procedure on the plurality of power domains excluding the second set of power domains comprises:

setting respective upper power limits for respective ones of the plurality of power domains excluding the second set of power domains; and

performing the first power capping procedure for the respective power domain based on the respective upper power limit.

36. The method of claim 29, wherein performing the second power capping process on the second set of power domains comprises:

setting respective upper power limits for respective power domains of the second set of power domains; and

performing the second power capping procedure for the respective power domain based on the respective upper power limit.

37. The method of claim 29, wherein the one or more instances comprise one or more performance important instances.

38. The method of claim 37, wherein the one or more performance important instances require a latency below a first threshold.

39. The method of claim 37, wherein the one or more performance important instances require an instruction execution rate above a second threshold.