KR20120046232A - Altering performance of computational units heterogeneously according to performance sensitivity - Google Patents

Abstract

One or more computational units are selectively modified in terms of performance depending on which of the one or more computational units of the computer system has higher performance sensitivity than other computational units.

Description

Differential Performance Change of Computation Units According to Performance Sensitivity {ALTERING PERFORMANCE OF COMPUTATIONAL UNITS HETEROGENEOUSLY ACCORDING TO PERFORMANCE SENSITIVITY}

FIELD OF THE INVENTION The present invention relates to power allocation in computer systems and more particularly to allocating power to improve performance.

Processors operate at various performance levels in an effort to match power consumption and workload requirements. Performance levels are typically determined by the voltage / frequency combinations used by the processor. As processors become more highly integrated with multiple cores and other functions, power and thermal considerations become of great importance.

In order to provide improved performance, one embodiment is to improve the system performance within a certain power envelope (eg, a constant power envelope) and the power headroom available in the system for the performance sensitivity of the computational unit to changes in execution capability resulting from frequency changes, for example. Enable analysis of the workload executed on computing units such as processing cores and graphics processing units.

Thus, in one embodiment, a method of operating a computer system including a plurality of computing units is provided. The method includes changing the performance of one or more computing units in accordance with the performance sensitivity of each of the computing units. The method may include varying the performance of one or more computational units depending on which of the one or more computational units has higher performance sensitivity than other computational units. In one embodiment, the computing units comprise a group of processing cores, and the method differs from the group to form a smaller group if the expected power margin when boosting the performance of the group of processing cores is less than zero. Removing from the group cores with lower performance sensitivity than those; And calculating a new expected power margin and determining if the new expected power margin is greater than zero if the performance of the smaller group of cores is boosted. If the new expected power margin is greater than zero, the performance of the smaller group of cores is boosted. The smaller group of cores can be boosted by increasing the frequency of the clock signal being supplied to at least these cores.

The performance sensitivity of each of the computing units may be determined according to the first and second performance metrics of the respective computing units determined at the first and second performance levels.

In yet another embodiment, an apparatus is provided that includes a plurality of computing units. The apparatus further includes a storage for storing each performance sensitivity for the computing units. The power allocation function is implemented in hardware, firmware, and / or software and boosts the performance of one or more of the computing units in accordance with performance sensitivity.

The power allocation function responds to which of the computing units have higher performance sensitivity than the others of the computing units.

The power allocation function may be configured to compare the performance sensitivity of each of the computing units with a threshold and to boost the computing units having a performance sensitivity higher than the threshold.

The power allocation function also removes one or more compute units from the compute units of the group in response to the expected power margin not sufficient to boost all of the cores of the group to the boosted performance state, and to generate a new expected power margin. Can be recalculated, and the removal is determined as one or more computing units in the group have a lower performance sensitivity than the other computing units in the group, and the removal and recalculation is such that the new expected power margin remains greater than zero. The process is repeated until the performance of the computing units can be boosted.

The present invention can be better understood by reference to the accompanying drawings and various objects, features, and advantages of the present invention will become apparent to those skilled in the art to which the present invention pertains.
1 illustrates a high level block diagram of an exemplary system-on-chip (SOC) system in accordance with one embodiment of the present invention.
2 illustrates a high level flow chart for profiling performance sensitivity to core frequency changes in accordance with one embodiment of the present invention.
3 illustrates frequency training at the system block diagram level.
4 illustrates additional aspects of frequency practice.
5 illustrates an exemplary flowchart of power reallocation in accordance with an embodiment of the present invention.
6 illustrates an example flowchart for adjusting the speed of computational units in accordance with frequency sensitivity.
Using the same reference numerals in different drawings indicates that the items are similar or identical.

When a processor integrated circuit is operating below a thermal design point (TDP), several methods have been proposed that opportunistically increase the performance level of CPU cores on multi-core processors (eg, raise the frequency). come. The actual thermal point at which the integrated circuit operates may be determined by thermal measurement, measurement of switching behavior, or measurement of current. These approaches allow the operating frequencies of the CPU cores to be raised together to improve performance when there is headroom for the estimated power, current, or heat under a given TDP, and when the operation is exceeding its limits. Allows the operating frequency of the CPU cores to be reduced. These approaches assume that when the frequencies of all running CPU cores are raised in a coordinated manner, they are operating at their maximum performance state.

Another approach provides reallocation of power between CPU cores. Cores at P0 (the highest performance state set by the operating system) are reassigned by reallocating power headroom available to other core (s) whose performance state is below a certain threshold (defined as lower performance state). It can be over-clocked.

The above approaches to uniformly increase power for all cores or one or more cores based on the performance states of the cores allow power to be reallocated from idle computing units, but dither frequency or Treat all running units uniformly when boosting the steady state frequency. However, some running cores or other computational units may get little or no performance gain from higher core frequencies, while other cores or computational units may place workloads at higher sensitivity to an increase in core frequency. It may be processing. Selectively distributing power between cores or other compute units running on the basis of frequency sensitivity can increase overall system throughput for heterogeneous workloads or multithreaded workloads with heterogeneous threads. It requires an effective approach to identify the workload's sensitivity to changes in core frequency.

1 illustrates an exemplary System on a Chip (SOC) 100 at a high level that includes one embodiment of the present invention. The SOC 100 may be referred to as multiple CPU processing cores 101, a graphics processing unit (GPU) 103, an I / O bridge 105 (in some embodiments, named South-Bridge). And a North-Bridge 107 (which in some embodiments may be combined with a Memory Controller). The power allocation controller 109 is a functional element that controls the allocation of thermal design point (TDP) power headroom to on-die components or on-platform components. to be. The performance analysis control logic 111 analyzes the performance sensitivity of the cores and other computational units as further described herein. Note that although power allocation control 109 and performance analysis center 111 are shown as being part of north-bridge 107, other embodiments may be located elsewhere in SOC 100.

The Thermal Design Point (TDP) represents the power that can be consumed by the entire SOC, which includes factors such as form-factor, available cooling methods, AC adapter / battery, and voltage regualtor. Depends on. SOC performance is optimized within the current TDP, and in one embodiment the power limit corresponding to the TDP never exceeds. Assume the SOC power limit is SOC_TDP_Limit. SOC characterization is typically based on allocating maximum power for each on-die components while remaining within SOC_TDP_Limit. This is accomplished by setting the highest operating point so that power does not exceed the assigned envelope, even if the maximum expected operation is performed at the highest operating point (at frequency F and voltage V). For example, suppose the maximum power of a four-core SOC is limited to a 40w TDP envelope. Table 1 lists the power budget allocated for each of the on-die components.

 On-die component Allocated power  Core 0 8w  Core 1 8w  Core 2 8w  Core3 8w  GPU 5w  Memory controller 2w  I / O bridge 1w  total 40w

The 8w power budget is the limit that defines the nominal peak operating point (F, V) of the core, and the 5w power budget is the limit for the GPU. However, this assignment is conservative because it assumes simultaneous use of all on-die components and is only nominally maximum. In practice, most applications are either CPU-bounded or GPU-bounded. Even if an application operates both computing engines together (eg, video playback offloads some tasks to the processor cores) it does not use all four processor cores. Even CPU constrained client applications mostly use 1 to 2 processor cores (1 to 2 thread workload) and only a few applications have enough parallelism to use all 4 cores over a long period of time. Has

One embodiment reallocates power from running or less running components to running components by allocating more power to running components. For example, in the workload example where two of the four cores are idle and the GPU is running at half the power, Table 2 shows a table of power budgets that reflect this state.

 On-die component Allocated power Remarks  Core 0 16.75w Cores can operate at higher F, V to fill new power headroom  Core 1 16.75w Cores can operate at higher F, V to fill new power headroom  Core 2 0.5w Assume an idle core consumes 0.5w  Core3 0.5w Assume an idle core consumes 0.5w  GPU 2.5w  Memory controller 2w  I / O bridge 1w  total 40w

Core 0 and Core 1 are allocated 16.75 watts to improve overall CPU throughput. The operating points F and V of both cores can be increased to fill the new power headroom 16.75w instead of 8w. As an alternative, the power budget of only one core is increased to 25.5 watts, while the other core may remain with a power budget of 8 watts. In this case, a core with an increased power budget can be boosted to a much higher operating point (F, V), so that a new power headroom 25.5w can be utilized. In this particular case, the decision of whether to boost two cores equally or provide all available power headroom to one core depends on what is the best way to improve overall SOC performance.

Boost  Sensitivity Exercises ( Boost Sensitivity Training ) And data structures

According to one embodiment, one method of determining how to allocate power between Core 0 and Core 1 to attempt and achieve improvement in performance gain is that which of the two cores (if any) is subject to frequency increase, for example. Is it better to take advantage of the increase in performance provided by that? The change in execution capability may also be provided by, for example, a change in the amount of cache available on the core, the number of pipelines operating on the core, and / or a change in the instruction fetch rate. In order to assess which of the cores can better utilize the increase in execution capability, in one embodiment performance sensitivity to frequency changes and / or other changes in execution capability of each computing unit (also referred to herein as boost sensitivity) Also referred to) is determined and stored in units of computation units.

2, a high level flow chart is illustrated for profiling performance sensitivity to core frequency changes in accordance with one embodiment of the present invention. First, at 201 a predefined low frequency clock signal is applied to a CPU core that is analyzed for a predetermined time or for a programmable time (eg, 100 us to 10 ms). During this time, hardware performance analysis control logic (see element 111 in FIG. 1) samples and averages instructions per cycle (IPC) of the core (as reported by the core). The performance analysis control logic determines the first instructions per second (IPS) metric as the first performance metric based on the IPC × core frequency (low frequency or first performance level). The IPS metric may be stored in the temporary register "A". The performance analysis control logic then at 205 causes a predefined high frequency clock signal to be applied to the CPU core under analysis for the same predetermined or programmable time. At 207 the performance analysis control logic again samples and averages the core IPC (as reported by the core). The performance analysis control logic determines a second instruction per second (IPS) based on the IPC × core frequency (high frequency or second performance level) and stores the second IPC metric as a second performance metric in temporary register "B". The performance analysis control logic at 209 determines the difference in numbers and stores the result in the performance or boost sensitivity table as performance sensitivity along with the number of cores under analysis and the number of process contexts running on the CPU cores during analysis. . Note that other performance changes may be utilized instead of or in combination with the frequency change to determine the boost sensitivity.

The context number can be determined by the contents of the CR3 register or by the hash of the CR3 register so that a shorter number can be stored. The difference in this figure indicates the boost sensitivity of the core. In other words, it represents the sensitivity to frequency changes of the core executing a particular process context. The higher the sensitivity, the greater the increase in performance obtained by increasing frequency. The same exercise shown in FIG. 2 can be applied to each processor core and any other component that can be boosted (over-clocked) above the nominal maximum power value, and the values are stored in the boost sensitivity table. The values in the boost sensitivity table can be sorted in descending order starting with the core with the highest boost sensitivity or other on-die component.

In other embodiments, the frequency sensitivity exercise may be any computing unit whose frequency can be changed to implement various performance states regardless of whether the computing units can be clocked (or overclocked) above the nominal power level. Can be applied to the In that way, the system can allocate the power budget from cores that are less sensitive to frequency changes to cores (or other compute units) that are more sensitive to frequency changes. In that way, cores or other computing units can be reduced in frequency in order to save power without significant performance loss for the SOC.

3 illustrates frequency practice at the system block diagram level. The exercises for core 301 are representative of the frequency exercises for each core. The clock generator 303 supplies the high frequency and low frequency clock signals to the core 301 during the frequency period as controlled by the performance analysis control logic 111. The core 301 provides the instruction value per cycle to the performance analysis control logic 111, which controls the method according to FIG. 2. 4 illustrates the measurement of the instruction per cycle (IPC1) determined by sampling and averaging for the first time and the frequency (FREQ1) supplied for the first time being multiplied in the multiplier 401. Similarly, the measurement of the instruction per cycle (IPC2) determined for the second time in the multiplier 403 is multiplied by the frequency (FREQ2) supplied for the second time. The difference of the utilization metrics determined at multipliers 401 and 403 is determined at summer 405. The result is boost sensitivity, which is stored in boost sensitivity table 407. The boost sensitivity table 407 stores, for each measurement, the result with the core number (C #), the process context running on the core, and the time that has elapsed since the last performance sensitivity measurement. The result is a performance metric or boost sensitivity, for example expressed as Instructions Per Second (IPS), calculated through the average IPC × core frequency. Note that the boost sensitivity table may be stored within SOC 100 (FIG. 1) or anywhere else in the computer system.

The boost sensitivity for each core can be tied to the current processor context, which can be approximated by the CR3 register value of x86 and tracked by the north-bridge. In one embodiment, when the context changes, the sensitivity is reevaluated. In another embodiment, the boost sensitivity for each context expires based on a fixed timer or a programmable timer (eg, after 1 ms to 100 ms). In another embodiment, both a timer and a context switch are used and if either occurs first, the boost sensitivity reassessment starts.

Thus, one embodiment of frequency practice has been described. The functions of FIG. 2 are implemented in hardware (eg, state machines of performance analysis control block 111), in firmware (microcode or microcontroller), or in software (eg, drivers, BIOS routines, or higher level software). Can be. The software is responsible for applying low and high frequency clock signals, receiving IPC values, averaging the IPC values, and performing other functions described in connection with FIG. The software may be stored in computer readable electronic, optical, magnetic, or other types of volatile or nonvolatile memory in the computer system of FIG. 1, and may be executed by one or more cores. In still other embodiments, the frequency sensitivity exercises illustrated in FIG. 2 and described above are implemented in software in part and in hardware depending on the needs and capabilities of the particular system. For example, the software may be responsible for maintaining the boost sensitivity table, reading the CR3 register to determine the process context, and maintaining software timers to re-determine the boost sensitivity, the hardware being notified by the software. Then apply clocks of the first frequency and the second frequency for an appropriate time and determine the average IPC. The software may be responsible for determining the IPS values.

Reallocation of Power Budget

The Boost Sensitivity Table (BST) is maintained as a result of a frequency sensitivity practice session for potentially boosted components. In other embodiments, the frequency sensitivity table is typically maintained as a result of frequency sensitivity exercises for all components whose performance can be adjusted through frequency (and voltage if necessary) adjustments. In one embodiment, power budget reassignment uses the information in the BST to “receive any on-die component (s) most responsive to boost and thus reassign higher TDP power margin when reassignment occurs. Is there ".

A particular processor core may be in one of N performance states. The performance state is characterized by a unique pair of core voltage values and frequency values. The highest performance state is typically selected and characterized such that the core power (dynamic + static) does not exceed the power budget allocated to that core due to any expected behavior. In current systems, core performance states are defined by operating system software and by current core utilization. In other embodiments, the core performance state may be specified by hardware based on the context currently executed by the core. Table 3 shows the performance states for an example system with four performance states (P0, P1, P2, P3), where the operating system (or any other higher level software) is These are states available for each core depending on the core utilization of the core. In one exemplary operating system, the time interval ranges from 1 msec to 100 msec. Two idle states are used when the OS (or any other higher level SW) sets the core to a low C-state. The C-state is the power state of the core. In this particular embodiment, the core may be in the IDLE state (when expected to be idle for a short time) or in a deep C-state. The highest operating point (P-Boost) is when the core power CoreBoostPwr exceeds the nominal maximum power budget allocated for that particular core.

Core
Performance status Operating point (F, V) Power Consumption
(Dynamic and static) Remarks P-Boost F-Boost
/ V-boost CoreBoostPwr Boost point.
Exceed the power budget of the core P0 F0 / V0 Core_Pwr0 Core power budget P1 F1 / V1 Core_Pwr1 P2 F2 / V2 Core_Pwr2 P3 F3 / V3 Core_Pwr3 IDLE Clock off
Low voltage Core_Idle_Pwr Deep C-state Clock off
On / off voltage Core_DeepCstate_Pwr Core is power gated or deep voltage is applied

GPU power state is traditionally controlled by software (graphics drivers). In other embodiments, it may also be controlled by hardware that tracks the behavior of the GPU and receives information from other graphics related engines (Unified Video Decoder (UVD), display, etc.). In one exemplary embodiment, the GPU may be in one of four power states as shown in Table 4.

Performance status GPU power consumption (dynamic and static) GPU-boost GPUBoostPwr GPU_P0 GPU_Pwr0 GPU_P1 GPU_Pwr1 GPU_P2 GPU_Pwr2 GPU_P3 GPU_Pwr3

In one embodiment, only two on-die components, the core processors and the GPU, can be boosted to higher performance points. I / O modules and memory controllers can contribute to the boost process of cores or GPUs by reallocating their "unused" power budget to these components, but they cannot be boosted themselves. In other embodiments, the memory controller may also be boosted by shifting Dynamic Random Access Memory (DRAM) and its frequency to a higher operating point.

One embodiment of efficiently allocating power to computational units is based on permanently tracking available power headroom, or TDP power margin.

SOC_TDP_Margin is calculated by subtracting the sum of the power consumption of all on-die components in SOC_TDP_Limit, where SOC_TDP_Margin = SOC_TDP_Limit-core (i) power-GPU power-memory controller power-I / O bridge power. Any change in the on-die components state triggers an update of the SOC_TDP_Margin value. In one embodiment, the state change that triggers the update is a change in performance or power state or a change in application / workload behavior. In other embodiments, the change in state that triggers the update may be a process context change or may be either a process context change or a performance state change. In one embodiment, any event that results in a change in power consumed by a component, such as a change in performance / power state or a change in application / workload behavior, may serve as an event that triggers a change in state.

In general, the power (voltage x current) of a particular computing unit is based on the clock signal frequency, the supply voltage, and the amount of activity in that computing unit. The specific approach to determining the power of each computing unit may vary depending on system capabilities and needs and may be implemented based on hardware and / or software approaches. For example, in one approach, the computing unit calculates and reports the average power value as dynamic power + static power. Dynamic power can be calculated as (average workload behavior / maximum behavior) × MaxPower, where MaxPower is the fused or settable value of the maximum dynamic power associated with the maximum behavior. The static power depends on the voltage at which the computing unit is operating and may be extracted from the table, or available from power management resources, or determined in hardware. Average workload behavior can be calculated as the average number of signal toggles passing through the computing unit over time, or the average IPC over time. The power calculation may also use software methods, in which the software (eg, driver) knows the behavior of the application running in the computing unit and uses an approach similar to that described above to determine the average power.

In one embodiment, only cores in the P0 state and GPUs in the GPU_P0 state may be reallocated power from other on-die components and boosted to higher performance points. This is based on the observation that the core is in the P0 state or the GPU is in the GPU_P0 state is essentially based on the observation that the currently running task is hints (computationally bounded) provided by higher level software such as the OS or some graphics drivers. will be. In other embodiments, the core and / or GPU may be boosted when in other non-idle states.

FIG. 5 illustrates an exemplary flow diagram of the operation of one embodiment of power allocation controller 109 (FIG. 1) for allocating power. At 501, the power allocation controller waits for state changes, such as performance states, application / behavior changes, or process context changes, for any on-die component. If a state change occurs, TDP_SOC_Margin is tracked at 503 and a determination is made at 505 whether the margin is greater than zero. If not greater than zero, go to 501. If the margin is greater than zero, this means that there is a headroom that can boost one or more cores, and a check is made at 507 to see if any CPU core is in the P0 state. In this particular embodiment, only cores at P0 can be boosted. If there are no cores at P0, then check the GPU power state at 523. If at least one core is at P0, the power allocation controller checks whether there is enough space to boost all P0 cores by calculating a new TDP_SOC_Margin = TDP_SOC_Margin-(CoreBoostPwr-Core_Pwr) for all cores at P0 at 509 do. The new TDP_SOC_Margin is the expected margin given that all cores in P0 are boosted. TDP_SOC_Margin is the current margin value. CoreBoostPwr is the core power when boosted and Core_Pwr is the current core power in the P0 state. At 511 the power allocation controller checks if the new margin is greater than zero. If so, there is enough space to boost all P0 cores, at 515 all cores are boosted, and TDP_SOC_Margin is updated. Then go back to 501 and wait for another state change.

If the margin at 511 is not greater than zero, go to 517 and find some margin if possible. Cores with the highest sensitivity are identified. This can be done, for example, by accessing the boost sensitivity table provided by the boost sensitivity exercise discussed above. At 519, cores in the P0 state are sorted in descending order of boost sensitivity, for example. Thus, the ones at the bottom are least sensitive to frequency increase. At 521, the power allocation controller removes the cores with the lowest boost sensitivity from the list one by one and recalculates the new TDP_SOC_Margin as in 509 for the remaining cores in the list. In other embodiments, all cores with boost sensitivity below a predetermined or programmable threshold are removed from the list at the same time. The reason for doing so is to prevent wasted power by boosting cores that will not increase performance. If the new TDP_SOC_Margin is greater than zero, the P0 cores still on the list are transitioned to P-boost and TDP_SOC_Margin is updated.

At 523, the power allocation controller checks to see if the GPU is in GPU_P0 state. If not, return to 501 and wait for a state change. If the GPU is in the P0 state, the power allocation controller calculates the new TDP_SOC_Margin from the current TDP_SOC_Margin from the current TDP_SOC_Margin at 525 to calculate the new TDP_SOC_Margin to determine if there is enough headroom to boost the GPU. do. At 527, the power allocation controller checks to see if the new margin is greater than zero, if it is greater than zero, transitions the GPU to a boosted state, updates TDP_SOC_Margin, and returns to 503 for another component in any component. Wait for status change. If there is not enough margin, go back to 503.

Thus, one embodiment has been described that finds that margin by allocating power to computational units at P0 when there is sufficient margin and excluding computational units that are less sensitive to frequency boost. In other embodiments, the frequency boost is provided only to computational units that have a sufficiently high boost sensitivity, e.g., above a predetermined or programmable threshold, to ensure surplus power. In this way, increased performance can be provided while attempting to maintain reduced power consumption if possible.

The functions of FIG. 5 may be implemented in hardware (eg, state machines), in firmware (microcode or microcontroller), or in software (eg, drivers, BIOS routines, or higher level software) to allocate power based on boost sensitivity. It may be implemented or in any suitable combination of hardware and software. Assuming that the boost sensitivity information is available through the boost sensitivity exercise, in one embodiment the software may be informed of the change in state of any component and implement the approach described with respect to FIG. The software may be stored in computer readable electronic, optical, or magnetic volatile or nonvolatile memory in the computer system of FIG. 1, and may be executed by one or more cores. In still other embodiments, the functions of FIG. 5 may be implemented in software, in part in hardware, depending on the needs and capabilities of a particular system.

The availability of boost sensitivity information can be used by the SOC in various ways. Speed regulation of the central processing unit (CPU) is an example of such use. Suppose a GPU-limited application is running. That is, an application running on a GPU is limited by the GPU's performance, for example, because its current performance state is lower than required for that particular application. In this case, CPU cores can be speed regulated (the performance of which is limited) by imposing a P-state limit on all CPU cores (eg, P-state limit = P2 state). This will release the power margin available to the GPU. In one embodiment, GPU constrained or CPU constrained applications are identified based on data indicating how busy a particular core or GPU is.

Alternatively, only cores with the lowest performance sensitivity to frequency can be speed adjusted to the P-state limit. For example, in a four-core system, the two cores with the lowest IPS sensitivity to core frequency change according to the boost sensitivity table can be speed regulated by imposing P-state limit = P2, while the state of the other cores. May remain unchanged. This will release for the GPU a power margin equivalent to ((Core_Pwr0-Core_Pwr2) x 2), where Core_Pwr0 is the power consumed by the core in the P0 state and Core_Pwr2 is the power consumed by the core in the P2 state.

In yet other embodiments, when a CPU constrained (operation constrained) application (application constrained by the performance of one or more processing cores) is running, the frequency is increased because the applications are often executed on a subset of the available cores. Cores that are less sensitive to (or reduce) can be speed adjusted to provide extra margin to other cores. GPU-limited applications are applications that are limited by the performance of the GPU.

6 illustrates a high level flow chart for speed regulation of performance based on boost sensitivity information. At 601, CPU constrained or GPU constrained applications are identified. At 603, the stored boost or performance sensitivity information is reviewed, and at 605 execution such as a decrease in frequency, voltage, amount of cache available to the core, number of pipelines running in the core, and / or instruction fetch rate. A subset of computational units, such as processing cores, for example, is identified to adjust speed based on a subset of cores that are less sensitive in terms of performance to the reduction in capability. The performance of the subset is limited at 607 and the power headroom made available through speed control at 609 is provided to the computational unit (s) running CPU constrained and / or GPU constrained applications. The functions described in FIG. 6 may be implemented in power allocation controller 109 or may be implemented using higher level software or both hardware and software.

If the application mainly uses CPU cores, the GPU can be speeded up by imposing a GPU P-state limit lower than GPU_Pwr0 or by speeding up the GPU's instruction / memory traffic stream. If the speed regulated GPU power is equivalent to GPU_Pwr2, surplus power margins GPU_Pwr0-GPU_Pwr2 may be reallocated to boost one or more CPU cores according to the boost sensitivity table values.

When computationally constrained workloads run on multi-core processors or GPUs, the memory can also be speed regulated. One method is to stall all other accesses to DRAM by multiple cycles to reduce the dynamic portion of DRAM I / O and DRAM DIMM power by nearly twice. Another approach may involve shutting down multiple available memory channels and also releasing some ratio of DRAM I / O and DRAM DIMM power. Reduced DRAM I / O power can be reallocated to the GPU or CPU cores depending on the utilization of the GPU or CPU cores and the BST values (if CPU cores are concerned), thus increasing overall SOC performance throughput. It leads. The DRAM DIMM may not be part of the SOC, in which case the power budget is not part of the SOC TDP. However, in situations where reduced DRAM DIMM power margin can be reallocated back to SOC TDP, surplus margin can be used to boost the GPU or some CPU cores.

Although circuits and physical structures are generally assumed for some embodiments of the present invention, in modern semiconductor design and fabrication, the physical structures and circuits are suitable for use in subsequent design, test, or manufacturing steps. It will be appreciated that it may be implemented in a descriptive form. Structures and functions presented as separate components in example configurations may be implemented as a combined structure or component. The invention provides both circuits, systems of circuits, related methods, and computer readable media encodings of such circuits, systems, and methods as described in the description of the invention and as defined in the appended claims. It is considered to include. As used herein, computer readable media includes at least disk, tape, or other magnetic, optical, semiconductor (eg, flash memory card, ROM), or electronic media.

Thus, various embodiments have been described. It should be noted that the description of the invention presented herein is exemplary and is not intended to limit the scope of the invention set forth in the appended claims. For example, the computing units may be part of a multi-core processor, but in other embodiments, the computing units may be in separate integrated circuits that may be packaged together or separately. For example, the graphics processing unit (GPU) and the processor may be separate integrated circuits packaged together or separately. Various modifications and variations can be made to the embodiments disclosed herein based on the detailed description set forth herein without departing from the scope of the invention set forth in the appended claims.

Claims (15)

A method of operation of a computer system comprising a plurality of computational units,
Varying the performance of one or more of the computational units in accordance with the performance sensitivity of each of the computational units.
How computer systems work. The method of claim 1,
Modifying the performance of the one or more computing units by boosting the performance of the one or more computing units according to which of the one or more computing units has a higher performance sensitivity than other computing units. doing
How computer systems work. The method of claim 1,
Comparing the performance sensitivity of each of the computing units to a threshold and changing the performance of the computing units in accordance with the comparison.
How computer systems work. The method of claim 1,
The one or more computing units whose performance changes are in the same power state before the performance changes, and the same power state is nominally the maximum power state.
How computer systems work. The method of claim 1,
The computing units comprise a plurality of processing cores in a group, and the method
Removing from the group one or more processing cores having a lower performance sensitivity than other processing cores among the processing cores of the group until the expected power margin is greater than zero for the processing cores remaining in the group; And
Altering the performance by boosting the performance of the cores remaining in the group;
How computer systems work. The method of claim 1,
The computing units comprise a plurality of processing cores and the method
If the expected power margin when boosting the performance of the group of processing cores is less than zero,
Removing from the group cores having a lower performance sensitivity than others in the group to form a smaller group; And
Calculating a new expected power margin and determining if the new expected power margin is greater than zero if the performance of the smaller group of cores is boosted;
If the new expected power margin is greater than zero for the smaller group of cores, modifying the performance by boosting the performance of the smaller group of cores; And
If the new expected power margin is still less than zero for the current group, then remove another core from the smaller group with a lower performance sensitivity than the other cores in the smaller group to form another smaller group. Further comprising the step of
How computer systems work. The method of claim 6,
Determining the new expected power margin in accordance with a current actual power margin-(Boost Power-Current Power), wherein the boosted power is the power of the smaller group of cores operating at the boosted power level. Wherein the current power is the power of the smaller group of cores operating at current power levels, and the current actual power margin is the power margin corresponding to the current power consumption of the computing units.
How computer systems work. The method of claim 1,
Modifying the performance is to boost the performance of the one or more computing units.
How computer systems work. The method of claim 1,
Accessing a storage to determine a performance sensitivity of each of the computing units, the storage storing performance sensitivity corresponding to respective process contexts executed on each of the processing cores.
How computer systems work. A plurality of computing units;
A storage unit which stores respective performance sensitivitys for the computing units; And
A power allocation function configured to boost performance of one or more of the computing units in accordance with the performance sensitivitys.
Device. The method of claim 10,
The power allocation function is responsive to one or more of the computing units having a higher performance sensitivity than others of the computing units.
Device. The method of claim 10,
The power allocation function is configured to compare the performance sensitivity of each of the computing units with a threshold and to boost the computing units having a performance sensitivity higher than the threshold.
Device. The method of claim 10,
The power allocation function also removes one or more computation units from the group of computation units in response to an expected power margin not sufficient to boost all of the cores of a group to a boosted performance state, and the removal is performed by the group. The one or more computing units of are determined to have a lower performance sensitivity than others of the computing units of the group, and the removal and recalculation are those remaining of the computing units in which the new expected power margin is greater than zero. Repeated until you can boost the performance of
Device. 14. The method according to any one of claims 10 to 13,
The apparatus includes at least one integrated circuit, and the computing units include at least one of processing cores, a memory controller, and a graphics processing unit, wherein the power allocation function is on hardware, firmware, and computer readable media. Implemented with one or more of the software stored
Device. The method of claim 10,
The performance sensitivity of each of the computing units is determined according to a first performance metric and a second performance metric of each of the computing units determined at a first performance level and a second performance level.
Device.

Images