Adaptive Power Management

Abstract

Techniques for adaptive device power management are described. A hardware computing unit detects the launch of an application by an operating system (OS) executing on the hardware computing unit. The hardware computing unit identifies the launched application and determines whether a hardware profile associated with the application exists. The hardware profile includes one or more hardware parameters that result in optimal performance in terms of power consumption by the hardware computing unit when executing the launched application. Based on determining that a hardware profile exists, a power policy of the OS is updated for the launched application, and a driver updates a power state of the hardware computing unit based on the new power policy.

Description

[Technical field]

[0001] The present invention relates to the field of computing devices, and in particular to adaptive power management thereof. [Background technology]

[0002] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Thus, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0003] Power and performance are important measurements for computing devices: computing devices running various loads are primarily optimized for performance, however, most computing environments (e.g., mobile computing) also have strict power constraints.

[0004] In addition to mobility, power is the primary resource consumed when heavy computationally intensive workloads are executed. Such computationally intensive workloads significantly increase the power consumption of computing systems using common or different workload specific engines (e.g., video, cryptography, direct memory access, decryption, image signal / unit processing engines). This consumption may be constraining data center / cloud environments in terms of financial cost and capacity. In addition, with the proliferation of computing systems, power consumption by computing devices has become a major environmental challenge. For example, computationally intensive workloads may cause much more pollution (in terms of the generation of required electricity) than an average automobile.

[0005] Therefore, next generation computing devices strive to maximize performance, while also ideally intending to reduce power consumption. To measure advancement, perf-per-watt is a key metric for processing unit performance and power to indicate the overall efficiency of any processing unit. The perf-per-watt metric measures the rate of computation by a processing unit per watt of power consumed to accomplish the computation. With the advancement of computationally intensive applications and global races in various computing fields such as Deep Neural Network (DNN) development, cryptocurrency mining, cloud computing, etc., such power and performance metrics are becoming more important to end users and companies providing cloud platforms.

[0006] One approach to improve performance per watt metrics is to switch power consumption based on the type of workload / application. With such an approach, for example, a computationally intensive, I / O intensive workload context is detected. Based on such context, a request is submitted to the computing device to execute the workload with optimal performance at optimal power consumption. To achieve this dynamic behavior, the computing device hardware may be designed with multiple performance / power states. For example, if an operating system (OS) determines that the context of an application is computationally intensive, the OS requests the computing device to execute the workload in the device's highest performance state.

[0007] However, using this approach, for long running computationally intensive applications, the computing device is always in its highest performance and power consumption state.

[0008] Running in the highest performance state will ultimately lead to overheating of the computing device and subsequent thermal-based throttling. Additionally, a computing device in its highest performance state will consume the most power, lowering its performance per watt metric.

[0009] In the drawings of specific embodiments, like reference numbers refer to corresponding parts throughout the drawings. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram illustrating a computer system 100 in which an embodiment of the present invention may be used. [Diagram 2] FIG. 2 is a block diagram illustrating an adaptive real-time power management system (ARTPMS) for power-optimizing execution of a workload(s) in one embodiment. [Diagram 3] FIG. 4 is a sequence diagram illustrating a process for adaptive real-time power management in one embodiment. [Figure 4] 1 is a flowchart illustrating a process for generating a power policy for a running application and a hardware computing unit associated with the hardware computing unit in one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the present invention may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0012] (overview) The approach herein describes adaptive power management for a hardware computing unit. In one embodiment, an operating system (OS) executing a workload on the hardware computing unit applies hardware parameter(s) of the hardware computing unit to generate a power policy for execution. The term "hardware computing unit" herein refers to a hardware processor, a hardware core, a hardware thread, a hardware computation circuit block, a hardware engine, or a computing device including any one or more of the above. Non-limiting examples of a hardware computing unit are a GPU, a CPU, a direct memory access (DMA) engine, a graphics (GFX) engine, or a computing device including one or more GPUs and a CPU. The term "hardware parameter" herein refers to a parameter of the hardware computing unit that influences a decision to change a power state of the hardware computing unit. The OS may apply a value(s) of the corresponding hardware parameter received from a device interface application (driver) of the computing device to determine whether to change a power state of the computing device.

[0013] In one embodiment, at initialization of a computing device, an OS receives values ​​of one or more hardware parameters of a hardware computing unit(s) that executes a workload of the OS. The OS uses the hardware parameter values ​​to generate a power policy for the workload. The term "power policy" as used herein refers to a policy that describes the power state that the OS sets for the hardware computing unit(s) that executes a workload.

[0014] Unlike a context-based power policy, the OS may fine-tune the power policy for workloads of the same context. Two computationally intensive workloads may have different tuning parameters resulting in different power policies. Based on the specific workload / application and hardware parameter values, the OS may change the power state of the hardware computing unit while executing the computationally intensive workload. For example, unlike a context-based power policy, the OS may determine to lower the power state (reduce the clock frequency, voltage and / or other settings that save power consumption) even while executing the computationally intensive workload. Although such a change in power state may seem to adversely affect performance, the OS performs the switch to a lower power state when the OS determines that part(s) (operations / instructions) of the workload being executed are not computationally intensive (e.g., there is no job submission to the hardware computing unit, such as when memory or I / O operations are executed).

[0015] In such an embodiment, the power policy is customized for each workload, but only the OS determines this power policy. Once determined, during the execution of the workload, the OS instructs the driver to change the hardware computing unit power state from one state to another state according to the power policy. Thus, the hardware computing unit(s) switch between a performance optimized state and a power consumption optimized state according to the policy. However, the hardware computing unit(s) themselves have no way to further optimize the power policy for a particular workload, even if the power policy can be further improved based on the specifications of the hardware computing unit(s) as applied to that particular workload.

[0016] In another embodiment, a profile of settings of hardware parameters of a computing device is generated for the workload or user application. The setting(s) of the hardware parameter(s) may be heuristically selected to provide the best performance per watt on the computing device with minimal degradation (if any) to performance. The term "hardware parameter profile" or "hardware profile" refers to a set of values ​​for corresponding hardware parameters that provide optimal performance for power consumption by the computing device. When a user application is launched, a driver identifies the application and a corresponding hardware parameter profile is retrieved. The selection of the hardware parameter profile may be further based on the computing device or hardware processing unit(s) on which the workload is executed. Once the hardware profile is retrieved, the driver communicates one or more hardware parameter values ​​to the OS. The OS uses the hardware parameter values ​​to generate and implement an updated power policy. The updated power policy is specific to both the workload and the hardware computing unit on which it is at least partially executing. The OS then adjusts the power state of the hardware computing unit based on the updated power policy.

[0017] (System Overview - Computer System) According to one embodiment, a user application having one or more workloads may be executed by one or more computer systems. A computer system may include one or more application / workload specific integrated circuits (ASICs) or digital electronic devices such as field programmable gate arrays (FPGAs) that are persistently programmed to execute user application instructions. A computer system may include one or more general purpose hardware processors that are programmed to execute user application instructions in firmware, memory, other storage, or combinations thereof. A computer system may also combine a general purpose hardware processor with custom hardware logic (e.g., an ASIC or FPGA) to execute user application instructions. A computer system may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that incorporates hardwired and / or program logic for executing user application instructions.

[0018] For example, Figure 1 is a block diagram illustrating a computer system 100 in which an embodiment of the invention may be used. Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a hardware processor 104 coupled to bus 102 for processing information. Hardware processor 104 may be a computing device such as, for example, a general-purpose microprocessor, and may include one or more hardware processing units.

[0019] Computer system 100 also includes a main memory 106, such as a random access memory (RAM) or another dynamic storage device, coupled to bus 102 for storing information and instructions executed by processor 104. Main memory 106 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 104. Such instructions, once stored in a non-transitory storage medium accessible to processor 104, may be executed by computer system 100 to perform operations specified in a user application.

[0020] Computer system 100 further includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104. A storage device 110, such as a solid state disk, magnetic disk, or optical disk, is provided and coupled to bus 102 for storing information and instructions.

[0021] Computer system 100 may be coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 114, including alphanumeric and other keys, is coupled to bus 102 for communicating information and command selections to processor 104. Another type of user input device is a cursor control 116, such as a mouse, trackball, or cursor direction keys, for communicating directional information and command selections to processor 104 and for controlling cursor movement on display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify a position in a plane.

[0022] The computer system 100 may execute user application instructions using additional computing devices 105, such as customized accelerated computing devices, one or more ASICs or FPGAs, firmware, and / or program logic that in combination with the computer system performs the operations of the user application. According to one embodiment, operations of the user application are performed by the computer system 100 in response to the processor 104 and / or the additional computing devices 105 executing one or more sequences of one or more user application instructions contained in the main memory 106. Such instructions may be read into the main memory 106 from another storage medium, such as the storage device 110. Execution of the sequences of instructions contained in the main memory 106 causes the processor 104 and / or the additional computing devices 105 to perform the process steps described herein.

[0023] The term "storage media" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical, solid-state or magnetic disks, such as storage device 110. Volatile media include dynamic memory, such as main memory 106. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge.

[0024] Storage media is distinct from but may be used in conjunction with transmission media, which media involves transferring information between storage media. For example, transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 102. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0025] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 104 and / or additional computing devices 105 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit the instructions over the Internet. A networking device of the computer system 100 may receive the data and appropriate circuitry / firmware may place the data on the bus 102. The bus 102 carries the data to the main memory 106, from which the processor 104 or additional computing devices 105 retrieve and execute the instructions. The instructions received by the main memory 106 may optionally be stored on a storage device 110 either before or after execution by the processor 104 and / or additional devices.

[0026] (System Overview - Adaptive Real-time Power Management System) 2 is a block diagram illustrating an adaptive real-time power management system (ARTPMS) for power optimizing execution of a workload(s) in one embodiment. ARTPMS 200 may be part of computer system 100 and may include one or more of the components described above. In one embodiment, ARTPMS 200 includes a computing device 216 for executing one or more programmed instructions as directed by an operating system (OS) 220.

[0027] Processor 104 or additional computing device 105 may be an example of computing device 216. Computing device 216 may execute commands and programs of OS 220 and its applications, such as user applications 226. In one embodiment, the commands and programs are for selected functions, such as graphics and non-graphics operations suitable for performing parallel processing. Computing device 216 is used to perform graphics pipeline operations, such as pixel operations, geometry calculations, and rendering of images to display device 112, based on commands received from processor 104 and / or additional computing device 105. Computing device 216 may also perform computational operations unrelated to graphics operations, such as operations related to video, physics simulations, computational fluid dynamics, or other tasks, based on commands received from other processors (e.g., processor 104 and / or additional computing device 105, etc.).

[0028] Exemplary processor types for computing device 216 include a CPU, a GPU, a CPU and a GPU located on the same die, or one or more hardware computing units (eg, cores) 232A-232N.

[0029] The scheduler 236, in one embodiment, is configured to perform operations related to scheduling various execution units (e.g., workgroups and wavefronts) on the different computing units 232A-232N. The execution of processing tasks on the computing device 216 is suitable for general computation or graphics related operations such as pixel value calculations, vertex transformations, and other graphics operations. The pipeline 234 accepts processing commands from memory or additional computing devices (e.g., 105) and thus, in one embodiment, provides computation tasks to the hardware computing units 232A-232N for parallel execution.

[0030] Computing device 216 may be configured by OS 220 of ARTPMS 200 for power management using device interface applications 225 (e.g., kernel mode drivers, user mode drivers, universal mode drivers), also referred to herein as "drivers." In one embodiment, OS 220 may communicate with firmware 206 via drivers 225 to configure computing device 216, such as to change the power state of computing device 216.

[0031] Driver 225 may maintain hardware parameter profile(s) 224 for various applications or groups thereof. Profile(s) 224 may include predetermined (e.g., determined prior to OS 220 initialization or user application 226 runtime) hardware parameter value(s) for optimal execution of the application on computing device 215, hardware computing units 232A-232N, and / or any identifiable class of such devices.

[0032] When executing applications 226, OS 220 communicates with computing device 216 (e.g., processor 104 or additional computing device 105) to control the operation of the hardware. In one embodiment, OS 220 performs the configuration by requesting driver 225 to request firmware 206 to change the power state(s) of hardware computing units 232A-232N of computing device 216. OS 220 requests such changes according to a power policy generated by OS 220 for computing device 216 and / or launched user applications 226.

[0033] For example, once a launched application 226 is identified, the driver 225 parses the hardware parameter profile 224 and retrieves the hardware parameter value(s) from the hardware parameter profile 224 for the identified application 226 and / or the computing device 216. The stored data is passed to the OS 220, which then generates a power policy for the computing device 216.

[0034] In one embodiment, during execution of application 226, firmware 206 of computing device 216 receives power state updates from OS 220. Firmware 206 may include corresponding configurations to control power management of hardware (e.g., CPU, graphics card) of computing device 216. By applying appropriate configurations (e.g., clock speed parameters, clock voltage parameters, clock gating parameters, power gating), firmware 206 sets the updated power state of computing device 216. Firmware 206 may be stored in non-volatile memory (e.g., hard disk, motherboard boot read only memory (ROM) and BIOS memory).

[0035] (Feature Overview) 3 is a sequence diagram illustrating a process of adaptive real-time power management, in one embodiment. One or more of the steps described below may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps illustrated in FIG. 3 should not be construed as limiting the scope of the invention. Additionally, the steps illustrated below may be modified based on the data structures used to store hardware profile data, the number and concurrency of execution of applications launched, and / or the particular state of the operating system and computing device executing one or more such applications.

[0036] At step 305, OS 220 is initialized. This may occur as part of booting up a computer system or spawning OS 220 in a virtual machine. During initialization, at step 310, OS 220 discovers and initializes installed devices, including computing device 216. Drivers 225 are initialized by communicating setting value(s) to firmware 206 at step 315 to initialize computing device 216, configuring computing device 216.

[0037] (Function Overview - Hardware Parameters) In step 320, the driver 225 provides the OS 220 with an original set of hardware parameter values ​​for the computing device 216. In one embodiment, the original set of values ​​is specific to the computing device 216, may depend on its internal architecture, and may describe its hardware capabilities. The hardware parameter values ​​are identifiable by the class, type, manufacturer, and / or model of the computing device 216.

[0038] In one embodiment, this initial set of hardware parameter values ​​is not specific to any application that may be executed on computing device 216. However, if any of the hardware parameter values ​​change, the power policy of the OS is affected for the particular application, and thus the power state that OS 220 sets while the application is running. Thus, the power consumed and performance obtained for the execution of the application may change.

[0039] The hardware parameter(s) may control power consumption and performance by indirectly affecting one or more power characteristics. An exemplary set of hardware parameters that control the entrance / exit hysteresis of the power characteristics may include one or more of the following: -Transition Latency: The time it takes for a component to return to its lowest power consumption state. Residency: The minimum time spent in a power state to compensate for the power and / or performance penalty associated with the switching state. In other words, the minimum time spent in a power state to make a transition worth the savings expected from the transition. Nominal Power: The power consumption of a device in a particular state, e.g., a minimum power consumption state and / or a maximum performance state.

[0040] Such parameters may control power features such as dynamic power management (DPM) features (e.g., clock speed parameters, clock voltage parameters, power gating, and clock gating parameters), memory timing features, and heat generation features (e.g., fan control, thermal design power (TDP)). Alternatively or additionally, such power features may be directly represented by a corresponding hardware parameter(s).

[0041] (Function Overview - Power Policy Generation) In one embodiment, the hardware parameter value(s) are used by OS 220 to generate a power policy for any one or more of its executing workloads / applications. Thus, after receiving the initial hardware parameters upon initialization in step 320, OS 220 may generate one or more power policies for various application(s) in step 321. Such power policies are not specific to the applications running on the hardware computing unit, since the initial hardware parameters used from step 320 are non-specific (static) to any of the applications and their workloads.

[0042] In one embodiment, the power policy of the computing device maps various conditions associated with the runtime of an application to corresponding power states. For example, if certain runtime statistics match the condition(s), the OS 220 requests the computing device 216 to be set to the corresponding power state of the mapping. Thus, for a given runtime statistic of an application, the power policy determines a) whether to transition the computing device to a different power state, b) which power state to transition to, and / or c) how long the optimal duration to be in a particular power state (e.g., in one embodiment, the minimum time to spend in a power state to compensate for the power and / or performance penalty associated with switching power states).

[0043] Thus, depending on what has been executed (or is predicted to be executed) by the application, OS 220 determines the optimal power state for such execution. In step 322, OS 220 may set such power state(s) on computing device 216 via driver 225 in communication with firmware 206. Execution-specific power states result in better performance per watt than context-based power management (where, for a compute-intensive workload, the clocks are always set to a high level (and therefore high power consumption) regardless of what operations are being executed within the compute-intensive workload).

[0044] In addition, the power policy generated by OS 220 may further take into account limitations and characteristics of computing device 216, which are represented by the hardware parameters of computing device 216 received in step 320, as described above. In one embodiment, the hardware parameters affect the mapping of execution to power states and may affect OS parameters (e.g., transition latency, residency, and / or nominal power). For different computing devices (and thus different sets of hardware parameters), the same runtime statistics of the same application may result in different power states.

[0045] (Function Overview - Power Policy Optimization) The limitations and characteristics of the computing device 216 may affect different applications differently. As described above, power consumption may be further optimized by customizing the power policy for each application when applied to the hardware computing unit on which the application executes. By using the same hardware parameter values ​​for any application, the OS 220 assumes that the limitations and characteristics of the computing device 216 affect all applications in the same way.

[0046] In one embodiment, an application is run with various hardware parameter values ​​until a particular set of hardware parameter values ​​is heuristically selected for the application as having the best performance-per-watt metric without significant performance degradation. Prior to execution by OS 220, various benchmark applications, photo editing applications, cryptocurrency mining applications, etc. are run on various hardware computing units, including computing device 216. For each application (or group thereof) and computing device pair (or class thereof), a set of hardware parameter values ​​that results in an optimal performance-per-watt metric for the desired performance is selected. A driver for one or more hardware computing units may store hardware parameter profiles with optimal hardware parameter values, each associated with a particular application and a particular hardware computing unit of one or more hardware computing units. Alternatively, hardware parameter profiles may exist for a group of applications, a class / type / device / system of a hardware computing unit, or a combination thereof. For example, driver 225 may include a hardware parameter profile with optimal hardware parameter values ​​for a group of graphic editing applications of which application 226 is a member, and for a particular model of GPU to which computing device 216 belongs.

[0047] Upon launch of an application, driver 225 may determine the application and provide hardware parameter value(s) corresponding to the application and the hardware computing unit. At step 325, OS 220 receives a request to run an application, such as application 226. At step 335, OS 220 launches application 226 for execution on at least computing device 216. Based on information associated with the application, OS 220 may generate a power policy to be applied to computing device 216 while executing the application.

[0048] In step 336, driver 225 may detect, as an example, that the application submitted to computing device 216 for execution is application 226. If application 226 has a hardware parameter profile, in step 338, driver 225 updates the hardware parameters of OS 220 with the settings from hardware profile(s) 224. When OS 220 generates a power policy for application 226 in step 340, the power policy is based on the application 226-specific hardware parameters. Driver 225 thereby influences the power policy of OS 220 to harmonize the power policy with the characteristics and limitations of the hardware computing unit that apply to application 226.

[0049] 4 is a flow chart illustrating a process for generating a power policy for a hardware computing unit associated with a running application and hardware computing, in one embodiment. One or more of the steps described below may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps shown in FIG. 4 should not be construed as limiting the scope of the invention. Additionally, the steps shown below may be modified based on the data structure used to store the hardware profile data.

[0050] In step 410, an application launch in the OS 220 is detected by the ARTPMS 200. For example, the driver 225 of the computing device 216, the hardware computing unit on which the application (e.g., application 226) runs, detects the launch of the application.

[0051] In an embodiment where another application is already running, the process may determine whether to continue the steps with the newly launched application. The process may compare the priority of the newly launched application with the priority of the currently running application to determine whether to go ahead and update the hardware parameter(s) for the newly launched application. For example, if the newly detected application has a higher priority, the process proceeds to the next step. Otherwise, if the newly launched application has a lower priority than the currently running application, in this example, the process ends. The priority may be represented by an identifier (e.g., the higher the identifier, the higher the priority) and may be stored in the hardware profile of the application. A user may set a priority for the application via a user interface (UI). The request received from the UI may include the priority of the application(s) or group(s) for the computing device(s) or class(es). The process updates the appropriate entry of the application in the hardware profile with the new priority. Alternatively or additionally, the priority may be assigned by the OS.

[0052] In another embodiment where another application is already running, the process may decide to continue with the newly detected application regardless of the already running application, and thus the process may override the hardware profile of the already running application with the hardware profile of the newly detected application, if one exists (see step 430).

[0053] In step 420, the process identifies the application submitted for execution. The application may be identified by identification information received by driver 225 from OS 220. For example, driver 225 may receive the name of an executable file (e.g., the name of the application) or a process ID assigned by OS 220 and use such identification information to look up hardware profile(s) 224.

[0054] In step 430, the process determines whether a hardware profile exists for the computing device 216 and the launched application. For example, the process searches the hardware profile(s) 224 to determine whether a hardware profile is associated with the launched application 226 and the computing device 216. The computing device 216 may be identified by a device description, which may include one or more of a device name, a model name, a serial number, a part number, a device identifier, a version, and a stock keeping unit (SKU). If a hardware profile is not identified, the process determines which group(s) of the application that launched the application 226 is a member of. If a hardware profile is identified for such a group, a hardware profile exists for the launched application 226. Similarly, the process may test whether there is a hardware profile for the class of computing device 216 that is also associated with a group or the application 226 itself.

[0055] For example, the "FAHBench" application is launched on a computing device 216 that has a "Navi 21" device description. Once the application is identified, driver 225 searches the blob file to determine whether a hardware profile exists for the pair of the "FAHBench" application and the "Navi 21" computing device. If not, driver 225 may check whether a hardware profile exists for the GPU benchmark application to which the FAHBench application belongs, for the "Navi 21" computing device, or for the class of GPU to which the "Navi 21" computing device belongs.

[0056] If, at step 430, it is determined that a hardware profile exists for the launched application and the computing device 216, the process proceeds to step 440, where the hardware parameter value(s) are retrieved from the identified hardware profile. At step 450, the process requests the OS 220 to update the hardware parameter values ​​with the retrieved hardware parameter values ​​for the execution of the application.

[0057] Conversely, if in step 440, driver 225 determines that no hardware profile exists for the launched application, the process proceeds to step 460 and skips sending an updated hardware profile. Thus, OS 220 continues to use the original / previous hardware parameters. For example, OS 220 may continue to use the hardware parameters received at the initialization of OS 220 to run the launched application.

[0058] Regardless of which hardware profile parameters are used, the process generates a power policy for computing device 216 in step 470. Similarly, continuing with Figure 3, regardless of whether optional step 338 is performed, in step 340 OS 220 generates a power policy for application 226.

[0059] Based on applying the policy, OS 220 may determine to change the power state of computing device 216. If a change in power state is determined, in step 350 OS 220 instructs firmware 206 by requesting driver 225 to set the power state of computing device 216 to the new power state.

[0060] For example, if the runtime statistics indicate a dominance of no-operation (NOP) instructions or memory operations, OS 220 may instruct driver 225 to set the power state to the lowest power consumption state according to the generated policy. Conversely, if the runtime statistics indicate a dominance of computing operations, OS 220 may instruct driver 225 to set the power state to the highest power consumption (highest performance) power state according to the generated policy.

[0061] In one embodiment, the driver 225 sets the computing device 216 to a particular power state at step 350 by requesting the firmware 206 to change the configuration of the computing device 216. For example, the change in power state may include changing the configuration regarding the frequency of clock cycles and / or the voltage of the computing device 216. A power state having a lower frequency clock or a lower voltage is a power consumption optimized power state, and a power state having a higher frequency clock or a higher voltage is a performance optimized power state.

[0062] In one embodiment, in step 355, driver 225 detects the exit / completion of a previously running application, e.g., application 226. Upon such detection, in step 360, driver 225, in one embodiment, may provide initial hardware parameter(s) to OS 220 to update. In such an embodiment, for future launched applications that do not have a hardware profile with driver 225 for computing device 216, OS 220 generates an updated power policy with the original hardware parameters. In step 365, OS 220 may update the power state of computing device 216 via driver 225 and request such update from firmware 206. Thus, in such an embodiment, the previous power policy optimized for the previously running application may not adversely affect the execution of future application(s).

[0063] (Improved power performance metrics) Table 1 shows example metrics for the benchmark "FAHBench" application run using various techniques. As shown in the example of Table 1, even when the "FAHBench" application does not have a hardware profile ("static profile"), the application performs with a 24% performance-per-watt improvement over the context-based power management technique. Such improvement occurs without any performance degradation in execution (1.23% performance improvement).

[0064] In an example where "FAHBench" has a specific hardware parameter profile ("adaptive profile") for the hardware computing unit to adapt to the application, the application achieves an additional 35.98% improvement in performance per watt metric compared to 24% for a static profile without an application-specific adaptive profile. Similarly, no performance degradation occurs compared to the context-based technique, an improvement of 0.35%.

[0065] [Table 1]

[0066] Table 2 shows example metrics for the "cb_vl_video_proc" application, a video processing application, run using various techniques. Similar to the benchmark application metrics, the video processing application performs with significant performance-per-watt improvements over the context-based power management technique for both the static and adaptive profile power management techniques (see Table 2, "Performance / Watt" row in the "Static / Context" column and the "Adaptive vs. Context" column). In particular, the adaptive profile technique has a nearly 150% improvement in performance-per-watt metrics over the static technique, 79% compared to 113.15%. Notably, this improvement occurs with a negligible degradation to performance, -0.4% (see Table 2, "Performance Score" row in the "Adaptive vs. Context" column).

[0067] [Table 2]

[0068] Table 3 shows example metrics for the "cb_bitcoin" application, a cryptocurrency mining application, run using various techniques. As shown in the example of Table 3, even when the "cb_bitcoin" application does not have a hardware profile ("static profile"), the application still runs with an 8.4% performance-per-watt improvement over the context-based power management technique. However, such improvement comes at the expense of an 8.8% performance degradation at runtime, which may not be acceptable for such a workload.

[0069] Unlike the performance degradation of the static profile technique, with the adaptive technique (with a specific hardware profile), the application has a lower performance degradation (3.39% performance degradation) compared to that of the context-based technique. However, the performance per watt metric is also improved by 8.5% in this example compared to the context-based technique. From the end user's perspective, the adaptive profile power management technique can provide reasonable performance while saving a lot of power (i.e., monetary cost).

[0070] [Table 3] Thus, in these examples, the adaptive real-time power management technique improves the application's performance-per-watt metric without degrading the application's performance.

[0071] In the above specification, embodiments of the invention are described with reference to numerous specific details that may vary from implementation to implementation. Thus, the specification and drawings should be considered in an illustrative and not a restrictive sense. The only exclusive indication of the scope of the invention, and what is intended by the applicant to be the scope of the invention, is the literal equivalent range of the set of claims issuing from this application in the particular form in which such claims are issued, including any subsequent amendments.

Claims

1. 1. A computer-implemented method comprising: Detecting a launch of an application that is at least partially executed on a hardware computing unit; determining whether a hardware profile exists associated with the application based on identifying the application; and updating a power state of the hardware computing unit based on a new power policy generated based at least in part on the hardware profile associated with the application based on determining that the hardware profile exists. method.

2. determining whether there is a hardware profile associated with the application includes determining whether the hardware profile is associated with the hardware computing unit; 2. The method of claim 1.

3. A group of applications is associated with the hardware profile; determining whether there is a hardware profile associated with the application includes determining whether the application is part of a group of applications; 2. The method of claim 1.

4. The hardware profile is an application hardware profile, and each of the plurality of hardware profiles including the application hardware profile is associated with a corresponding application and a corresponding hardware computing unit; each hardware profile includes one or more hardware parameter values ​​that, when applied to a corresponding hardware computing unit, provide optimal performance-per-watt performance for a corresponding application on the corresponding hardware computing unit; 2. The method of claim 1.

5. applying an original hardware profile of the hardware computing interface before launching the application; the original hardware profile includes one or more hardware parameter values ​​that are non-specific to the application; 2. The method of claim 1.

6. The hardware profile includes one or more values ​​of any one or more of the following hardware parameters: transition latency describing the time to transition to a power state, residency describing the time to remain in a transitioned power state that is worth transitioning to, and nominal power representing the minimum available power consumption; 2. The method of claim 1.

7. identifying the application by retrieving one or more identification information about the application, the identification information including one or more of an executable file name of the application, a process name of the application, or a process identifier of the application; 2. The method of claim 1.

8. the application is a first application and the hardware profile is a first hardware profile; The method comprises: Detecting a launch of a second application that executes at least partially on the hardware computing unit; and determining whether a second hardware profile associated with the second application exists based on identifying the second application; and continuing to execute the second application using current hardware parameter values ​​based on determining that the second hardware profile is not present.

2. The method of claim 1.

9. the application is a first application and the hardware profile is a first hardware profile; The method comprises: Detecting a launch of a second application that executes at least partially on the hardware computing unit; and determining whether a second hardware profile associated with the application exists based on identifying the second application, the second hardware profile including one or more second hardware parameter values ​​that are different from one or more first hardware parameter values ​​of the first profile; and updating a power state of the hardware computing unit based on a second power policy that differs from the new power policy and that is generated based at least in part on the second hardware profile associated with the second application based on determining that the hardware profile exists.

2. The method of claim 1.

10. the application is a first application and the hardware profile is a first hardware profile; The method comprises: Detecting a launch of a second application that executes at least partially on the hardware computing unit; and determining that the second application has a higher execution priority than the first application; based on determining that the second application has a higher execution priority than the first application and identifying the second application, determining that a second hardware profile exists associated with the application, the second hardware profile including one or more second hardware parameter values ​​that are different from one or more first hardware parameter values ​​of the first profile; updating a power state of the hardware computing unit based on a second power policy different from the new power policy and generated based at least in part on the second hardware profile associated with the second application.

2. The method of claim 1.

11. one or more processors; and one or more storage media storing a set of instructions including instructions that, when executed by the one or more processors, cause the device to perform the method of any one of claims 1 to 10. system.

12. One or more storage media storing instructions, The instructions, when executed by one or more hardware processors, cause a method according to any one of claims 1 to 10 to be performed. storage medium.

13. Apparatus comprising means for carrying out the method of any of claims 1 to 10.

Images