Patent Description:
Processors and other semiconductor devices generate heat when they are performing computations and/or other operations. Furthermore, more intensive computational workloads typically correspond to greater increases in heat. Thus, higher performance computing devices typically experience greater thermal stresses which can deleteriously impact the reliability and/or useful life of such devices.

<CIT> describes receiving a signal from one or more sensors in a data processing system. A determination is made as to whether the signal indicates that one threshold in a plurality of thresholds has been reached or exceeded. Responsive to the signal indicating that one threshold in the plurality of thresholds has been reached or exceeded, a determination is made as to whether the one threshold is a low temperature threshold or a high temperature threshold. Responsive to the one threshold being a low temperature threshold, one of a plurality of actions is initiated to increase a temperature of the data processing system.

<CIT> describes a memory device or an apparatus that includes a memory device may have circuitry configured to heat the memory device. The circuitry configured to heat the memory device may be activated, deactivated, or otherwise operated based on an indication of a temperature (e.g., of the memory device). In some examples, activating or otherwise operating the circuitry configured to heat the memory device may be based on an operating mode (e.g., of the memory device), which may be associated with certain access operations or operational states (e.g., of the memory device).

Further embodiments thereof are presented in the dependent claims.

In general, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts. As used herein, connection references (e.g., attached, coupled, connected, and joined) may include intermediate members between the elements referenced by the connection reference and/or relative movement between those elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and/or in fixed relation to each other. As used herein, stating that any part is in "contact" with another part is defined to mean that there is no intermediate part between the two parts.

Unless specifically stated otherwise, descriptors such as "first," "second," "third," etc. are used herein without imputing or otherwise indicating any meaning of priority, physical order, arrangement in a list, and/or ordering in any way, but are merely used as labels and/or arbitrary names to distinguish elements for ease of understanding the disclosed examples. " In such instances, it should be understood that such descriptors are used merely for identifying those elements distinctly that might, for example, otherwise share a same name. As used herein "substantially real time" refers to occurrence in a near instantaneous manner recognizing there may be real world delays for computing time, transmission, etc. Thus, unless otherwise specified, "substantially real time" refers to real time +/- <NUM> second.

Many semiconductor-based processors (e.g., central processing units (CPUs), graphics processing units (GPUs), accelerators, etc.) are housed in a ball gird array (BGA) package. In addition to solder joints within the packages (die-die, die-to-package substrate), BGA packages include an array of metallic balls that may be individually connected to a printed circuit board (PCB) via a corresponding array of solder joints. The reliability of such joints over time (e.g., the useful life of such joints) and other integrated circuit package and/or packaging materials can be negatively impacted when exposed to thermal stresses such as relatively frequent fluctuations in temperatures over relatively large temperature ranges. While such thermal fluctuations may occur in any type of processor (whether associated with a BGA package or otherwise), they can have especially significant impacts on processor packages intended for high performance computing applications (e.g., supercomputers and/or data centers). By reducing the thermal fluctuations of an integrated circuit, one can reduce the reliability limiting stress on that integrated circuit and/or its associated package, thereby increasing the reliability lifetime of the processor package.

High performance computing exacerbates the problems associated thermal fluctuation induced stress because high performance processors are typically implemented in larger packages that operate at higher powers to perform more computationally intensive tasks. Such conditions result in greater maximum temperatures (as such packages can produce more heat) and, thus, larger fluctuations in temperatures between when a high performance processor is being used and when it is idle. Furthermore, high performance computing applications often involve relatively frequent changes between active periods when a processor is being run at or near its full capacity (thereby producing large amounts of heat) and idle periods when the processor is not being used (during which the processor may cool off to near ambient temperatures).

As used herein, an active period of a processor is when the processor is in an active state. As used herein, an active state is when the processor is either executing a standard workload (SWL) or the processor is scheduled to execute an SWL. As used herein, an SWL is any workload associated with particular tasks to be completed by the processor as part of its normal or standard operation. Many SWLs are user workloads that are initiated, provided, and/or defined by a user of the associated computing device. However, other SWLs may be implemented automatically to accomplish particular tasks (e.g. maintenance tasks) without specific input from a user. As used herein, an idle period of a processor is when the processor is in an idle state. As used herein, an idle state is when the processor is not executing any SWLs and is not scheduled to execute any SWLs.

Temperature fluctuations in a GPU implementing typical high performance computations for a standard workload (SWL) including five computational kernels (K1 through K5) is shown in <FIG>. While <FIG> is described with reference to a GPU, similar temperature profiles may occur in any other type of processor and teachings disclosed herein may be suitably adapted to such processors. In the illustrated example, the shaded bands <NUM>, <NUM>, <NUM>, <NUM>, <NUM> represent active periods of the GPU corresponding to the five computational kernels being executed. The periods of time outside and between the active periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM> correspond to idle periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> when the GPU is in an idle state (i.e., not executing instructions or scheduled to execute instructions). As shown in the illustrated example, the temperature of the GPU during the active periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM> is represented by a solid line and the temperature of the GPU during the idle periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> is represented by a line with alternating dots and dashes. In the illustrated example of <FIG>, during the first idle period <NUM> (e.g., prior to beginning the first active period <NUM>), the temperature of the GPU is at a true idle temperature <NUM> (Tidle) of the GPU, which is typically slightly above an ambient temperature <NUM> (Tambient). The particular temperature values for the idle temperature <NUM> and the ambient temperature <NUM> can differ from system to system and the associated environment and/or application for which the system is used. By way of example, the idle temperature <NUM> and the ambient temperature <NUM> of many systems are below <NUM>. During the first active period <NUM> (while the first kernel K1 is being executed), the temperature rises until it reaches a maximum temperature <NUM> (Tmax) and then hovers around that temperature until the first active period <NUM> is completed. As used herein, the maximum temperature <NUM> of a processor corresponds to the temperature reached by the processor when operating at the thermal design power (TDP) of the processor. The particular temperature value of the maximum temperature <NUM> can differ widely from system to system and the associated environment and application for which the system is used. By way of example, it is possible for the maximum temperature <NUM> of some systems to reach as high as <NUM> or higher. A processor is typically designed to reach its TDP when the processor is being driven to its full capability over a period of time. Many high performance computing applications drive processors to their full capabilities such that the processors will be operating at or near their TDP when in an active state. As a result, it is not uncommon for the maximum temperature <NUM> to be reached during the execution of SWLs as shown in <FIG>.

Following the first active period <NUM>, there is a brief idle period <NUM> during which the GPU is not performing any operations and, therefore, the temperature drops as heat is dissipated from the GPU. However, the duration of this second idle period <NUM> is not long enough for the GPU to cool very far before the second active period <NUM> is initiated. Although the second active period <NUM> is much shorter than the first active period <NUM>, the temperature of the GPU again reaches the maximum temperature <NUM> because the GPU was already relatively warm when the second active period <NUM> began. By contrast, the third idle period <NUM> is much longer than the second idle period <NUM>. As a result, during the third idle period <NUM> the temperature of the GPU drops nearly back down to the idle temperature <NUM> before rising again during the third active period <NUM>. The temperature then falls during a fourth idle period <NUM> before rising again during the fourth active period <NUM>. Thereafter, the temperature drops again and stabilizes at the idle temperature <NUM> during the fifth idle period <NUM> before again being driven to the maximum temperature <NUM> during the fifth active period <NUM>. Following completion of the fifth active period <NUM>, the GPU returns to an idle state (e.g., in a sixth idle period <NUM>) where the temperature of the GPU cools back down to the idle temperature <NUM>.

As shown in the illustrated example of <FIG>, there are relatively small fluctuations in temperature in the second, third, and fourth active periods <NUM>, <NUM>, <NUM> as well as in the second, fourth, and fifth idle periods <NUM>, <NUM>, <NUM>. While these fluctuations may cause some stress on the GPU, testing has shown that it is the relatively large temperature fluctuations that are most problematic to the reliability of a GPU over time. That is, the large temperature increases during the first and fifth active periods <NUM>, <NUM> coupled with the large temperature drops during the third and sixth idle periods <NUM>, <NUM> in <FIG> introduce significant thermal stresses on the solder joints and/or other interfaces of the GPU that can cause degradation and/or failure to occur much more quickly than if the GPU was only subjected to the smaller temperature fluctuations noted above. Particular temperatures changes that constitute relatively large temperature fluctuations as used herein may differ widely from system to system and/or the associated application for which the system is used. In some examples, the size of acceptable temperature fluctuations (e.g., fluctuations that do not constitute relatively large fluctuations that are undesirable) may depend on the level of reliability of the system desired. By way of example, in some examples, a temperature swing of at least <NUM> may be considered to be a relatively large temperature fluctuation the occurrence of which is to be reduced (e.g., minimized and/or avoided). In other examples, the threshold temperature delta that constitutes a relatively large temperature fluctuation may be higher (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.).

Examples disclosed herein reduce the frequency of large thermal fluctuations by reducing the amount by which the temperature of a processor cools during idle periods between adjacent active periods. More particularly, in examples disclosed herein the frequency of large thermal fluctuations are reduced by opportunistically causing the processor to execute workloads during the idle periods as needed to cause the processor to produce heat sufficient to maintain the temperature within a threshold range of the peak temperature reached during the active periods. In the illustrated example of <FIG>, the peak temperature corresponds to the maximum temperature <NUM>. However, in other examples, the peak temperature may be less than the maximum temperature <NUM>. The workload executed during the idle periods is referred to herein as an idle workload (IWL) to distinguish it from the SWLs executed during the active periods. In some examples, the IWL is controlled to only execute during the idle periods of the processor. As a result, the IWL has no impact on the performance of the GPU when the SWL is being executed because the SWL is only executed during the active periods and not the idle periods.

While the IWL does not affect the performance of the GPU when executing the SWL (because they are executed at different time), execution of the IWL does require additional power. However, this increase in power consumption is a trade-off made to achieve better reliability of the GPU over time (e.g., increase the useful life of the GPU). In some examples, the extent of excess power used to execute the IWL is reduced by setting a timeout period after which the IWL will not execute even if the temperature of the GPU will consequently drop below the threshold temperature above which the GPU was being maintained before the timeout period. That is, in some examples, rather than always maintaining the temperature of a processor within a threshold range of the peak temperature, execution of the IWL may timeout, thereby allowing the GPU to fully cool down during an idle period. This can save power in situations where an idle period extends for a relatively long duration of time. That is, there may be a long duration of time when there is no SWL to be executed such that there is no need to maintain the GPU at an elevated temperature and doing so unnecessarily consumes power. Limiting the implementation of the IWL to a timeout period ensures that the IWL does not unnecessarily consume power indefinitely when there may be extended periods of no standard (e.g., user) activity (e.g., no SWL to be executed).

<FIG> illustrates the temperature of the same GPU of <FIG> executing the same five-kernel SWL represented in <FIG> except with an IWL executed during at least some portion(s) of some of the idle periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> to maintain the temperature of the GPU above a fixed target temperature <NUM> (Ttarget). While <FIG> is described with reference to a GPU, teachings disclosed herein may be suitably adapted to any type of processor. In this example, the target temperature <NUM> is a configurable parameter that is set with a fixed temperature value defined based on known properties of the underlying processor (e.g., the GPU) in conjunction with expected uses of the processor. More particularly, in some examples, the target temperature <NUM> is defined to be within a particular range of an expected peak temperature for the processor (e.g., the maximum temperature <NUM> in <FIG>). In some examples, the particular range is defined to be less than the temperature differential of large thermal fluctuations that are to be avoided to improve the reliability of the processor. How large the thermal fluctuations need to be to constitute large thermal fluctuations may depend on the level of reliability and/or useful life desired for the processor and on physical characteristics of the processor, its packaging, the location where it is mounted (e.g., on a PCB), and/or the characteristics of the mounting mechanism employed (e.g., flip chip, conventional, solder type, etc.).

In the illustrated example of <FIG>, the target temperature <NUM> defines the temperature of the GPU at which an IWL procedure is armed or initiated. Thus, as shown in <FIG>, the point <NUM> where the temperature of the GPU reaches the target temperature <NUM> defines when the IWL procedure is armed or activated. The IWL procedure involves the monitoring of the temperature of the GPU during idle periods to identify conditions that trigger the execution of an IWL to maintain the temperature of the GPU within a threshold temperature range of the maximum temperature <NUM>. In other words, while the arming or enabling of the IWL procedure does not necessarily imply that a particular IWL will be executed, arming the IWL procedure at least initiates the system to begin monitoring for conditions that may call for an IWL to be executed.

In some examples, the threshold temperature range within which the IWL procedure maintains the GPU corresponds to the difference between the maximum temperature <NUM> and the target temperature <NUM>. In some examples, the temperature of the GPU is kept within this range (e.g., kept above the target temperature <NUM>) by executing an IWL in response to a trigger condition corresponding to the temperature of the GPU falling below a setback temperature <NUM> (Tsetback). In some examples, the trigger condition is limited to idle periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. That is, in some examples, no IWL is executed during an active period <NUM>, <NUM>, <NUM>, <NUM>, <NUM> even if the temperature drops below the setback temperature <NUM>.

In the illustrated example, the setback temperature <NUM> is a configurable parameter defined to be higher than the target temperature by a particular temperature difference or delta. Additionally or alternatively, in some examples, the setback temperature <NUM> may be defined as some temperature delta below the maximum temperature <NUM> (e.g., that is less than the difference between the maximum temperature <NUM> and the target temperature <NUM>). As shown in the illustrated example, during the second idle period <NUM>, the temperature of the GPU remains above the setback temperature <NUM>. As a result, there is no need to add heat to the GPU such that no IWL is executed in that period <NUM>. However, during the third idle period <NUM>, the temperature of the GPU does drop below the setback temperature. However, unlike the temperature cooling off to near the idle temperature <NUM> (as in <FIG>), in the illustrated example of <FIG>, once the temperature drops below setback temperature <NUM>, an IWL is executed by the GPU to produce heat, thereby maintaining the temperature of the GPU above the target temperature <NUM> and near the setback temperature <NUM>. In some examples, the IWL is executed entirely in the GPU (e.g., without writing to an off chip memory). In other examples, the IWL may be executed by the GPU in communication with a separate processor, memory, and/or IC package. In some examples, off chip operations may be implemented in a package that is adjacent to the GPU so that heat produced by the adjacent package contributes to increase the temperature of the GPU. In some examples, execution of the IWL may be continuous through the end of the idle period <NUM> (e.g., the IWL may include a set of commands that may loop indefinitely). In other examples, execution of the IWL may be intermittent with each instance heating up the GPU before there is a break in which the GPU cools down before another instance of the IWL is executed to again heat up the GPU. In some examples, this intermittent heating and cooling of the GPU around the setback temperature <NUM> incorporates some hysteresis such that the temperature of the GPU rises above the setback temperature <NUM> and falls below the setback temperature <NUM> as represented in <FIG>. In other examples, the intermittent heating and cooling of the GPU by intermittently executing instances of an IWL may maintain the temperature at or below the setback temperature <NUM> (and above the target temperature <NUM>) throughout the process. In some examples, execution of an IWL may be triggered when the temperature of the GPU drops to the target temperature <NUM> and execution of the IWL is stopped when the temperature returns to the setback temperature <NUM>. In some examples, execution of the IWL has no purpose other than to heat the GPU. In this manner, execution of the IWL can be interrupted at any time without any meaningful loss of data to quickly transition to executing SWL if a new active period begins during ongoing execution of the IWL. In some examples, execution of the IWL may provide a useful purpose that is secondary and/or separate to heating the processor. For instance, in some examples, a primary processor (CPU) may offload tasks to the GPU that serve a purpose to the operation of the primary processor. In some examples, such offloaded tasks may be non-critical tasks so that they can be terminated and/or interrupted to enable the GPU to transition to its primary purposes of executed SWLs. Additionally or alternatively, in some examples, other remoted devices (e.g., in an edge network) may provide requests to the GPU that serve as IWLs to heat the GPU during otherwise idle periods.

As shown by comparison with <FIG>, the execution of the IWL during the third idle period <NUM> as represented in <FIG> maintains the temperature of the GPU above the target temperature <NUM> throughout the entirety of the third idle period <NUM>. As a result, the large temperature drop represented in the third idle period <NUM> of <FIG> is avoided. Furthermore, the temperature of the GPU remains above the target temperature <NUM> through the third and fourth active periods <NUM>, <NUM> and the fourth and fifth idle periods <NUM>, <NUM>. As a result, the temperature of the GPU is already elevated when the fifth active period <NUM> begins, as represented in <FIG>, thereby avoiding the large temperature increase represented in <FIG> during the corresponding active period <NUM>. Thus, whereas the temperature profile of the GPU represented in <FIG> includes two large thermal fluctuations reaching up to around the maximum temperature <NUM> and down to around the idle temperature <NUM>, the temperature profile of the GPU represented in <FIG> includes only one such cycle through the high and low temperatures at the beginning and after the ending of the IWL procedure.

As shown in the illustrated example, the IWL procedure is associated with an IWL timeout period <NUM> that defines a duration for the IWL procedure beginning when it is first armed or initiated (e.g., when the temperature of the GPU first passes the target temperature <NUM>). After the timeout period <NUM> has elapsed, the IWL procedure is disarmed or deactivated meaning that the temperature of the GPU is no longer monitored for the trigger condition (e.g., dropping below the temperature setback <NUM> during an idle period) that causes execution of an IWL. Rather, as represented in <FIG>, after the IWL procedure is disarmed or disabled, the temperature of the GPU is allowed to fall below the setback temperature <NUM> and the target temperature <NUM> (e.g., during the sixth idle period <NUM>). If a subsequent SWL is executed that causes the temperature to again rise above the target temperature <NUM>, the IWL procedure would again be armed or enabled and continue for another timeout period <NUM>.

In the particular example of <FIG>, the timeout period <NUM> ends during the fifth active period <NUM>. However, this is merely a function of timing of the active periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of the illustrated example relative to the duration of the timeout period <NUM>. In other situations, the timeout period <NUM> may end during an idle period. For instance, assume that the SWL only included the first four kernels (K1 through K4) such that the entire time extending from the fifth idle period <NUM> through the sixth idle period <NUM> was one continuous idle period. In such a scenario, the IWL procedure would maintain the temperature of the GPU hovering around the setback temperature <NUM> (as represented by the last portion of the fifth idle period <NUM> in <FIG>) all the way until the IWL procedure is disarmed or terminated. After that point, the GPU would be allowed to cool to the idle temperature <NUM>. Notably, if there was no timeout period <NUM>, the IWL procedure would maintain the temperature of the GPU hovering around the setback temperature <NUM> indefinitely. Executing an IWL indefinitely with no subsequent SWL to execute is a waste of energy. Accordingly, applying the timeout period <NUM> to the IWL procedure serves to save power while still reducing the number of large thermal fluctuations.

In the illustrated example of <FIG>, the IWL timeout period <NUM> is a configurable parameter that is defined to have a fixed duration. In some examples, the duration of the timeout period <NUM> is defined based on a threshold frequency of large thermal fluctuations to which the GPU is to be subject. For instance, testing has shown that the reliability of processors begins to degrade significantly when such processors experience a significant amount of large thermal fluctuations during their user. What constitutes a significant amount of large thermal fluctuations depends on the particular processor being heated and cooled, the rate of the heating and cooling, and/or other factors. However, if the number of large thermal fluctuations within a given period that would begin to cause the reliability of a processor to degrade, it may be possible to select a suitable timeout period to avoid that number of fluctuations in the given period. For example, assume that a particular processor is found to begin to degrade when more than <NUM> large thermal fluctuations a day. In such a scenario, to guarantee that no more than <NUM> thermal fluctuations are experienced in a day, the timeout period <NUM> may be set to <NUM>/<NUM>th of a day (e.g., <NUM> minutes). In some examples, the timeout period <NUM> may be set for a longer or shorter period depending on the level of reliability desired and/or the importance of reducing power consumption. More generally, the timeout period <NUM> and/or any other parameter(s) defining the implementation of teachings disclosed herein may be modified in response to an ongoing quasi-static or dynamic reliability lifetime analysis and/or based on any other factors relevant to the particular scenario in which teachings disclosed herein are implemented. For instance, in some examples, the timeout period <NUM> depends on the time of day (e.g., shorter during evening hours when it is less likely to be used by a user), day of the week (e.g., shorter during weekends), time of year (e.g., winter versus summer), etc. In some examples, the timeout period <NUM> is determined based on historical usage patterns. In some examples, the timeout period <NUM> changes based on the number of thermal fluctuations that have occurred within a given period (e.g., the timeout period increases if fluctuations are observed relatively regularly and decreases if fluctuations are observed relatively rarely).

In some examples, rather than defining the timeout period <NUM> as a fixed duration measured from when the IWL procedure is first enabled or armed, the IWL procedure may be disabled or disarmed based on the duration and/or spacing of the active periods relative to the idle periods. For instance, in some examples, the IWL procedure is disarmed whenever a single continuous idle period extends beyond a threshold idle time period. That is, in some examples, a timer begins counting as soon as an idle period has begun. If a subsequent active period begins before the threshold idle period duration elapses, the timer is reset and does not begin counting again until the subsequent active period ends and a new idle period begins. However, if an idle period extends longer than the threshold idle period duration, the IWL procedure ends and is disarmed. In some examples, the threshold idle period duration is significantly less than the timeout period <NUM> described above so as to reduce the amount of time that power is consumed executing IWLs when there is no immediate need to maintain the GPU at an elevated temperature. While this approach can improve power efficiency, this approach may increase the total number of thermal fluctuations experienced over time if the active periods are spaced apart by more than the threshold duration but occur at a frequency that is more often than the timeout period <NUM> described above. To avoid this possibility, in some examples, the threshold idle time period only begins counting after the timeout period <NUM> has elapsed. That is, in some examples, the IWL procedure is configured to continue for at least the timeout period <NUM>. Thereafter, the IWL period only ends and is disarmed once a subsequent idle period extends longer than the threshold idle time period.

Defining a fixed target temperature <NUM> and an associated fixed setback temperature <NUM> as described in connection with <FIG> is suitable when the peak temperature reached by the GPU is relatively consistent and known in advance. For instance, fixed values for these parameters are often suitable for high performance computing applications where it is expected that the GPU will reach the maximum temperature <NUM> and that the maximum temperature is known. In some situations, the maximum temperature <NUM> may not be known and/or the usage of the GPU may be such that it does not always reach the maximum temperature <NUM>. Accordingly, in some examples, a target temperature may be defined dynamically relative to maximum and/or minimum temperatures observed for GPU during relevant periods of time as shown and described in connection with <FIG>.

In particular, <FIG> illustrates the temperature of the same GPU of <FIG> executing the same five-kernel SWL represented in <FIG> except with an IWL executed during at least some portion(s) of some of the idle periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> to maintain the temperature of the accelerator above a dynamic target temperature (represented over time by the line identified by reference numeral <NUM>). As with <FIG> and <FIG>, while <FIG> is described with reference to a GPU, teachings disclosed herein may be suitably adapted to any type of processor. As shown in the illustrated example, during the IWL procedure, the dynamic target temperature <NUM> is defined to be threshold or target temperature delta <NUM> below an armed maximum temperature of the GPU. As used herein, the armed maximum temperature is the maximum temperature of the GPU observed since the IWL procedure was first armed or initiated. Thus, in the illustrated example, at point <NUM> when the IWL procedure is first armed, the maximum temperature observed corresponds to the current temperature of the GPU. Thus, the initial armed maximum time corresponds to the temperature of the GPU at the time the IWL procedure is armed. As time progresses, the temperature of the GPU continues to increase. As a result, the armed maximum temperature also increases because each new sample of the temperature constitutes a new maximum since the IWL procedure was armed. If the current temperature of the GPU drops from a previously higher maximum (e.g., at the dip <NUM> in <FIG>), the armed maximum temperature does not drop but remains at the highest observed temperature. Thus, once the temperature of the GPU reaches the maximum temperature <NUM> (e.g., at point <NUM> in <FIG>), this will become the armed maximum temperature for the remainder of the IWL procedure. As defined above, the dynamic target temperature <NUM> is defined to be the target temperature delta <NUM> below the armed maximum temperature. Thus, as shown in the illustrated example, the dynamic target temperature <NUM> begins at the idle temperature <NUM> (which is the target temperature delta <NUM> below the temperature of the GPU at point <NUM> in this example) and varies over time to follow the increasing temperature of the GPU during the first active period <NUM>. Notably, the dynamic target temperature <NUM> remains constant during the dip <NUM> in the GPU temperature because the armed maximum temperature is also constant during the time. The dynamic target temperature <NUM> then rises in conjunction with the temperature reaching the maximum temperature <NUM> at point <NUM> and then the dynamic target temperature remains constant for the remainder of the IWL procedure.

As described above, the target temperature <NUM> in <FIG> is a fixed value that defines both the temperature at which the IWL procedure is armed or initiated and also the target temperature above which the GPU is maintained during the IWL procedure. By contrast, in the illustrated example of <FIG>, the temperature at which the IWL procedure is armed is defined independent of the dynamic target temperature <NUM> used during the IWL procedure. In particular, while the dynamic target temperature <NUM> during the IWL procedure is defined to be a target temperature delta <NUM> below the armed maximum temperature, the IWL procedure is first armed or activated when the temperature of the GPU reaches the target temperature delta <NUM> above a disarmed minimum temperature. As used herein, the disarmed minimum temperature refers to the minimum temperature of the GPU observed since the IWL procedure was last disarmed or ended. Thus, in the illustrated example, during the first idle period <NUM> the minimum temperature observed corresponds to the idle temperature <NUM>. Thus, the IWL procedure is armed when the GPU temperature rises to a temperature corresponding to the target temperature delta <NUM> above the idle temperature <NUM>.

As mentioned above, the dynamic target temperature <NUM> initially begins at the target temperature delta <NUM> below the temperature of the GPU at the time the IWL is initially armed. Inasmuch as the IWL procedure is initially armed when the GPU temperature is above the disarmed minimum temperature by the target temperature delta <NUM>, the initial temperature of the dynamic target temperature <NUM> corresponds to the disarmed minimum temperature prior to the IWL procedure being armed. This is the reason that the initial target temperature <NUM> corresponds to the idle temperature <NUM> when the IWL procedure begins as represented in the illustrated example of <FIG> as noted above. However, if the disarmed minimum temperature was higher than idle temperature <NUM> when the IWL procedure is initiated (e.g., the GPU did not have an opportunity to fully cool since the ending of a previous IWL procedure), the initial dynamic target temperature <NUM> would also be higher than the idle temperature <NUM>.

During the IWL procedure of <FIG>, the temperature of the GPU is monitored to identify a trigger condition to cause the GPU to execute an IWL to maintain the temperature of the GPU above the target temperature <NUM>. In the illustrated example, the trigger condition corresponds to the temperature of the GPU falling below a setback temperature (Tsetback) (represented over time by the line identified by reference numeral <NUM>). In some examples, the setback temperature <NUM> of <FIG> serves the same purpose as the setback temperature <NUM> described above in connection with <FIG>. However, unlike the setback temperature <NUM> of <FIG>, which is a fixed temperature, the setback temperature <NUM> varies across time relative to changes in the dynamic target temperature <NUM>. More particularly, the setback temperature <NUM> of <FIG> is a configurable parameter defined to be a setback temperature delta <NUM> above the target temperature <NUM>. Thus, as the target temperature <NUM> increases, the setback temperature <NUM> also increases. In this manner, regardless of how high the temperature of GPU rises (e.g., regardless of the armed maximum temperature), if the temperature begins to drop and decreases below the setback temperature <NUM>, the execution of an IWL will be initiated to prevent the temperature from falling as low as the target temperature <NUM>. As a result, large thermal fluctuations that can impose undue stress on the GPU are avoided during the IWL procedure.

As described above, the IWL procedure implemented in the illustrated examples of <FIG> and <FIG> limits the execution of IWLs to the idle periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM> so as to not interfere with the performance of the GPU during the active periods. In such an approach, there is still the possibility of large thermal fluctuations during the active periods <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. That is, in some situations, SWLs may be scheduled for execution, thereby establishing the GPU as being in an active state, but the SWLs may not require the GPU to operate at full capacity. As a result, the temperature of the GPU may drop to relatively low temperatures (e.g., below the target temperature <NUM>, <NUM>). In some examples, the possibility of such thermal fluctuations are assumed to be relatively rare and/or to have an acceptable impact on the reliability of the GPU in view of the importance of not interfering with the performance of the GPU. However, in some examples, if reliability is of greater concern to a user than performance, the IWL procedure may provide IWLs to the GPU for execution during the active periods if needed to maintain the temperature of the GPU above the target temperature <NUM>, <NUM>. In such examples, there would be no need to monitor or determine whether the GPU is in an active state or an idle state. Rather, the only trigger for the execution of an IWL would be whether the current temperature is above or below the setback temperature <NUM>, <NUM>.

As noted above, in examples where the execution of IWLs is limited to idle periods so as not to affect performance of the execution of any SWL during the active periods, there is a possibility that some large thermal fluctuations may occur within the active periods. In some examples, the IWL procedure includes a mechanism to disarm or deactivate prior to the timeout period <NUM> expiring in response to such situations so as not to exacerbate the problem and increase the frequency and/or extent of thermal fluctuations. For instance, assume the particular SWL executed by the GPU during the first active period <NUM> results in the temperature of the GPU initially rising enough to trigger the activation or arming of the IWL procedure and then dropping back down close to the idle temperature before the active period <NUM> ends. With the IWL procedure now armed, upon entering the following idle period <NUM>, the trigger condition for executing IWLs based on the temperature of the GPU being below the setback temperature <NUM>, <NUM> would be satisfied. As a result, the IWL procedure would provide IWLs to the GPU for execution to drive up the temperature of the GPU toward the setback temperature <NUM>, <NUM>. However, as can be seen, because the initial temperature of the GPU at the beginning of the idle period <NUM> was low (e.g., at or near the idle temperature), this process would produce a large thermal fluctuation rather than avoid it. Accordingly, in some examples, if a relatively large drop in temperature (e.g., above a threshold) is detected during an active period, the IWL procedure is automatically disarmed or deactivated.

<FIG> illustrates an example computing system <NUM> constructed in accordance with teachings disclosed herein. The example computing system <NUM> includes a processor <NUM> to execute SWLs provided by a user. The processor <NUM> may be any type of processor such as a central processing unit (CPU), graphics processing unit (GPU), an accelerator, etc. As shown in the illustrated example, the processor <NUM> includes an example workload scheduler <NUM> and one or more temperature sensor(s) <NUM>. The example workload scheduler <NUM> receives workloads submitted from a user (e.g., SWLs) and schedules the workloads for execution. The example temperature sensor(s) <NUM> monitor the temperature of the processor <NUM> and output signals indicative of the temperature. Thus, the temperature sensor(s) <NUM> are a means for sensing the temperature of the processor <NUM>. In some examples, one or more of the temperature sensor(s) are included within a package of the processor <NUM>. In some examples, one or more of the temperature sensor(s) <NUM> are mounted on a surface of a package of the processor <NUM>. In some examples, one or more of the temperature sensor(s) are mounted adjacent to a package of the processor <NUM> (e.g., on an adjacent PCB).

Additionally, the example computing system <NUM> of <FIG> includes an example thermal fluctuation controller <NUM> to reduce thermal fluctuations in the processor <NUM> due to the heating and cooling of the processor <NUM> during active and idle periods as outlined above in connection with <FIG>. That is, the example thermal fluctuation controller <NUM> monitors the temperature of the processor <NUM> and the activity of the processor <NUM> to provide IWLs for execution by the processor <NUM> at suitable times (e.g., during idle periods) to maintain the temperature of the processor <NUM> within a threshold range of a peak temperature. As represented in the illustrated example of <FIG>, the thermal fluctuation controller <NUM> is external to the processor <NUM> and associated with a separate processor. For example, the thermal fluctuation controller <NUM> may be implemented by a CPU that interacts with the processor <NUM>, which may be a GPU. In other examples, the thermal fluctuation controller <NUM> may be internal to and implemented by the processor <NUM> itself. In some examples, at least some functionalities of the thermal fluctuation controller <NUM> are implemented internally by the processor <NUM> and at least some functionalities of the thermal fluctuation controller <NUM> are implemented externally by a different processor.

As shown in the illustrated example of <FIG>, the thermal fluctuation controller <NUM> includes an example workload analyzer <NUM>, an example temperature analyzer <NUM>, an example idle workload controller <NUM>, an example timer <NUM>, example memory <NUM>, and an example idle workload database <NUM>. The example workload analyzer <NUM> analyzes the current state of the processor <NUM> to determine whether the processor <NUM> is currently active (e.g., executing or scheduled to execute a SWL) or currently idle (e.g., in an idle period). More particularly, in some examples, the workload analyzer <NUM> is in communication with the workload scheduler <NUM> of the processor <NUM> and/or has access to schedule information generated by the workload scheduler <NUM>. The workload analyzer <NUM> analyzes such schedule information to confirm whether any SWL submissions have been provided to the scheduler for execution. If at least one SWL submission is scheduled for execution, the workload analyzer <NUM> determines that the processor <NUM> is in an active state with pending SWLs to execute. If the schedule information indicates that no pending SWL submissions are scheduled to be executed, the workload analyzer <NUM> determines that the processor <NUM> is in an idle state. Thus, in some examples, the workload analyzer <NUM>, as a structure, is a means for analyzing a workload to determine whether the processor <NUM> is in an idle state or an active state. In some examples, the workload analyzer <NUM> is one of hardware, firmware, or software. In some examples, the workload analyzer <NUM> is a processor, a dedicated processor unit, a digital signal processor (DSP), etc. Alternatively, the example workload analyzer <NUM> may be a block of code embodied as transistor logic (firmware) or software.

The example temperature analyzer <NUM> is in communication with the temperature sensor(s) <NUM> of the processor <NUM> and/or has access to the temperature data output by the temperature sensor(s) <NUM>. In some examples, the temperature analyzer <NUM> analyzes the temperature data to determine a temperature of the processor <NUM>. In some examples, different portions of the processor <NUM> may be at different temperatures such that different temperature sensors <NUM> output different measured temperatures. In some examples, the temperature analyzer <NUM> identifies the highest reported temperature as the temperature of the processor <NUM> to be used in subsequent analysis. In some examples, a different temperature than the highest reported temperature may be used (e.g., the lowest reported temperature, an average of temperatures reported by some or all of the temperature sensors <NUM>, etc.). In some examples, the temperature analyzer <NUM> compares the temperature of the processor <NUM> to one or more parameters (e.g., thresholds, set points, temperature ranges, etc.) associated with the initiation and/or implementation of the IWL procedure discussed above in connection with <FIG>. For example, if a fixed target temperature <NUM> is defined, the temperature analyzer <NUM> compares the temperature of processor <NUM> to the target temperature <NUM> to determine when to arm or enable the IWL procedure. If a dynamic target temperature <NUM> is to be used, the temperature analyzer <NUM> compares the temperature of the processor <NUM> to the disarmed minimum temperature plus the target temperature delta <NUM> to determine when to arm the IWL procedure. Once the IWL procedure is armed, the temperature analyzer <NUM> compares the temperature of the processor <NUM> to the setback temperature (which may be a fixed setback temperature <NUM> as described in <FIG> or a dynamic setback temperature <NUM> as described in <FIG>) to determine whether an IWL needs to be executed to maintain the temperature of the processor <NUM> above the corresponding target temperature <NUM>, <NUM>. In some examples, the temperature analyzer <NUM> is one of hardware, firmware, or software. In some examples, the temperature analyzer <NUM> is a processor, a dedicated processor unit, a digital signal processor (DSP), etc. Alternatively, the example workload analyzer <NUM> may be a block of code embodied as transistor logic (firmware) or software. In some examples, the temperature analyzer <NUM> includes and/or is incorporated with the temperature sensor(s) <NUM>.

The example idle workload controller <NUM> of the illustrated example controls the initiation, operation, and termination of the IWL procedure. Thus, in some examples, the idle workload controller <NUM>, as a structure, is a means for controlling an IWL procedure. That is, when feedback from the temperature analyzer <NUM> indicates that the temperature conditions indicate the IWL procedure is to be armed, the idle workload controller <NUM> arms or initiates the IWL procedure. When feedback from the temperature analyzer <NUM> indicates the temperature of the processor <NUM> has dropped below the setback temperature <NUM>, <NUM>, the idle workload controller determines whether to submit an IWL submission to the workload scheduler <NUM> of the processor <NUM> to execute the IWL. In some examples, execution of an IWL is to be limited to idle periods. Accordingly, in some examples, the idle workload controller <NUM> also uses feedback from the workload analyzer <NUM> to determine whether the processor <NUM> is currently in an active state or an idle state. In some examples, the particular IWL provided to the processor <NUM> for execution is selected from the idle workload database <NUM>. In some examples, there may be multiple different IWLs that the idle workload controller <NUM> may select. The different IWLs may correspond to any suitable set of commands that may be provided to the processor for execution. Different IWLs may be defined to affect the temperature of the processor <NUM> in different ways (e.g., heat it faster or slower). In some examples, the IWLs are defined as relatively simply workloads that may be looped so that execution may be ongoing until such time as the IWL is no longer needed (e.g., the temperature of the processor <NUM> has been raised back up to or above the setback temperature <NUM>, <NUM>). In some examples, the IWLs are defined to have multiple threads to cause different execution units of the processor <NUM> to operate at the same time for a more evenly distributed heating of the GPU.

The example timer <NUM> of the example thermal fluctuation controller <NUM> is used by the idle workload controller <NUM> to determine when to end or disarm the IWL procedure. That is, in some examples, the idle workload controller <NUM> starts the timer <NUM> when the IWL procedure is first armed. When the timer <NUM> reaches the timeout period <NUM>, the idle workload controller <NUM> terminates or disarms the IWL procedure.

The example memory <NUM> is used to store values for the parameters used during the IWL procedure. In some examples, these values may be configured once by a user (or defined by an original equipment manufacturer) and remain fixed until changed by the user (e.g., the fixed target temperature <NUM>, the temperature setback <NUM>, the timeout period <NUM>, the target temperature delta <NUM>, the setback temperature delta <NUM>). In some examples, the values in the memory are updated on an ongoing basis based on changing circumstances (e.g., the dynamic target temperature <NUM>, the dynamic setback temperature <NUM>, the armed maximum temperature, the disarmed minimum temperature, the current temperature of the processor <NUM>, etc.).

While an example manner of implementing the thermal fluctuation controller <NUM> is illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the example workload analyzer <NUM>, the example temperature analyzer <NUM>, the example idle workload controller <NUM>, the example timer <NUM>, the example memory <NUM>, the example idle workload database <NUM>, and/or, more generally, the example thermal fluctuation controller <NUM> of <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example workload analyzer <NUM>, the example temperature analyzer <NUM>, the example idle workload controller <NUM>, the example timer <NUM>, the example memory <NUM>, the example idle workload database <NUM> and/or, more generally, the example thermal fluctuation controller <NUM> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example workload analyzer <NUM>, the example temperature analyzer <NUM>, the example idle workload controller <NUM>, the example timer <NUM>, the example memory <NUM>, and/or the example idle workload database <NUM> is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the example thermal fluctuation controller <NUM> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase "in communication," including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

Flowcharts representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the thermal fluctuation controller <NUM> of <FIG> is shown in <FIG> and <FIG>. The machine readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor and/or processor circuitry, such as the processor <NUM> shown in the example processor platform <NUM> discussed below in connection with <FIG>. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example programs are described with reference to the flowcharts illustrated in <FIG> and <FIG>, many other methods of implementing the example thermal fluctuation controller <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware. The processor circuitry may be distributed in different network locations and/or local to one or more devices (e.g., a multi-core processor in a single machine, multiple processors distributed across a server rack, etc.).

The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data or a data structure (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers) located at the same or different locations of a network or collection of networks (e.g., in the cloud, in edge devices, etc.). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement one or more functions that may together form a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by processor circuitry, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, machine readable media, as used herein, may include machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.

As mentioned above, the example processes of <FIG> and <FIG> may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

The flowchart of <FIG> represents example machine readable instructions to implement the thermal fluctuation controller <NUM> of <FIG> using a fixed target temperature <NUM> as described above in connection with <FIG>. The program of <FIG> begins at block <NUM> where the example temperature analyzer <NUM> obtains the current temperature of the processor <NUM>. At block <NUM>, the example idle workload controller <NUM> determines whether the IWL procedure is armed. If not, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the current temperature is at or above the target temperature <NUM>. If not, there is no need to arm the IWL procedure. Accordingly, control advances to block <NUM> where the thermal fluctuation controller <NUM> determines whether to continue the process. If so, control returns to block <NUM> to obtain an updated measurement of the current temperature. Returning to block <NUM>, if the example temperature analyzer <NUM> determines that the current temperature is at or above the target temperature <NUM>, control advances to block <NUM> where the example idle workload controller <NUM> arms the IWL procedure. In the illustrated example, arming the IWL procedure initiates the monitoring of the temperature of the processor <NUM> relative to the setback temperature <NUM>. Further, arming the IWL procedure includes starting the example timer <NUM> to count towards the timeout period <NUM>. In some examples, rather than starting a timer, the idle workload controller <NUM> may store the current time (as indicated by the timer <NUM>) in the example memory <NUM> as a point of reference to compare against the timeout period <NUM> as time progresses. After the IWL procedure is armed at block <NUM>, control advances to block <NUM>.

Returning to block <NUM>, if the example idle workload controller <NUM> determines that the IWL procedure is armed, control advances to block <NUM>. At block <NUM>, the example idle workload controller saves and/or updates (e.g., in the example memory <NUM>) an armed maximum temperature controller. That is, if the most recent measurement of the current temperature (obtained at block <NUM>) is the highest temperature observed since the IWL procedure was first armed, that temperature is set as the armed maximum temperature. If the current temperature is less than the armed maximum temperature, the armed maximum temperature remains unchanged.

At block <NUM>, the example idle workload controller <NUM> determines whether the timeout period <NUM> has elapsed. If not, control advances to block <NUM> where the example workload analyzer <NUM> determines whether any SWL is scheduled. If so, then no IWL is to be executed so as to not interfere with the performance of the processor <NUM> when executing the SWL. Accordingly, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the armed maximum temperature (set at block <NUM>) minus the current temperature (obtained at block <NUM>) satisfies (e.g., is greater than) a threshold. Block <NUM> serves to identify situations where large temperatures drops (e.g., exceeding the threshold) occur during an active period so as to not inadvertently cause the temperature of the processor <NUM> to increase during an idle period if it has already cooled during a preceding active period. Thus, if the threshold is satisfied (e.g., the difference between the armed maximum temperature and the current temperature exceeds the threshold), control advances to block <NUM> where the example idle workload controller <NUM> disarms the IWL procedure. Thereafter, control advances to block <NUM> to determine whether to continue the process as discussed above. If the example temperature analyzer <NUM> determines, at block <NUM>, that the threshold is not satisfied, control advances directly to block <NUM> such that the IWL procedure remains armed.

Returning to block <NUM>, if the example workload analyzer <NUM> determines that no SWL is scheduled, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the current temperature is lower than the setback temperature <NUM>. In some examples, if reliability is more important than performance and the potential for large thermal fluctuations during active periods are to be avoided, blocks <NUM> and <NUM> may be omitted. In such examples, if the timeout period has not elapsed (as determined at block <NUM>), control advances directly to block <NUM>. If the example temperature analyzer <NUM> determines, at block <NUM>, that the current temperature is not lower than the setback temperature <NUM>, then no action needs to be taken so control advances directly to block <NUM>. However, if the current temperature is lower than the setback temperature <NUM>, control advances to block <NUM> where the example idle workload controller <NUM> selects an IWL from the example idle workload database <NUM>. At block <NUM>, the example idle workload controller <NUM> provides the IWL to the processor <NUM> for execution. Thereafter, control advances to block <NUM>.

Returning to block <NUM>, if the example idle workload controller <NUM> determines that the timeout period <NUM> has elapsed, control advances to block <NUM> where the example idle workload controller <NUM> disarms the IWL procedure. Thereafter, control advances to block <NUM> to determine whether to continue the process as discussed above. If so, control again returns to block <NUM>. If not, the example process of <FIG> ends.

The flowchart of <FIG> represents example machine readable instructions to implement the thermal fluctuation controller <NUM> of <FIG> using a dynamic target temperature <NUM> as described above in connection with <FIG>. The program of <FIG> begins at block <NUM> where the example temperature analyzer <NUM> obtains the current temperature of the processor <NUM>. At block <NUM>, the example idle workload controller <NUM> determines whether the IWL procedure is armed. If not, control advances to block <NUM> where the example temperature analyzer <NUM> determines the current temperature is less than the disarmed minimum temperature. If so, control advanced to block <NUM> where the idle workload controller <NUM> updates the disarmed current temperature with the current temperature. That is, the current temperature becomes the new disarmed minimum temperature. Thereafter, control advances to block <NUM> where the thermal fluctuation controller <NUM> determines whether to continue the process. If so, control returns to block <NUM> to obtain an updated measurement of the current temperature.

Returning to block <NUM>, if the current temperature is not less than the disarmed minimum temperature, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the current temperature minus the disarmed minimum temperature is less than the target temperature delta <NUM>. If not, there is no need to arm the IWL procedure. Accordingly, control advances to block <NUM> where the thermal fluctuation controller <NUM> determines whether to continue the process. If the current temperature minus the disarmed minimum temperature is less than the target temperature delta <NUM>, control advances to block <NUM> where the example idle workload controller <NUM> arms the IWL procedure. In the illustrated example, arming the IWL procedure initiates the monitoring of the temperature of the processor <NUM> relative to the setback temperature <NUM>. Further, arming the IWL procedure includes starting the example timer <NUM> to count towards the timeout period <NUM>. In some examples, rather than starting a timer, the idle workload controller <NUM> may store the current time (as indicated by the timer <NUM>) in the example memory <NUM> as a point of reference to compare against the timeout period <NUM> as time progresses. After the IWL procedure is armed at block <NUM>, control advances to block <NUM> where the example idle workload controller <NUM> resets the disarmed minimum temperature to an upper bound. In some examples, the upper bound can be any suitable higher any expected temperature for the processor <NUM> (e.g., higher than the maximum temperature <NUM>). In this manner, whenever the IWL becomes disabled again, the current temperature of the processor <NUM> at that time will be less than the disarmed minimum temperature (as determined at block <NUM>) to then define the disarmed minimum temperature as the current temperature (at block <NUM>). After the disarmed minimum temperature is resent, control advances to block <NUM> to determine whether to continue the process.

Returning to block <NUM>, if the example idle workload controller <NUM> determines that the IWL procedure is armed, control advances to block <NUM>. At block <NUM>, the example idle workload controller <NUM> determines whether the timeout period <NUM> has elapsed. If not, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the current temperature is greater than the armed maximum temperature. If so, control advances to block <NUM> where the idle workload controller <NUM> updates the armed maximum temperature with the current temperature. That is, the current temperature becomes the new armed maximum temperature. At block <NUM>, the idle workload controller updates the setback temperature <NUM> based on the updated armed maximum temperature. More particularly, in some examples, the setback temperature <NUM> is defined as the armed maximum temperature minus the target temperature delta <NUM> plus the setback temperature delta <NUM>. Thereafter, control advances to block <NUM>. Returning to block <NUM>, if the current temperature is not greater than the armed maximum temperature, control advances directly to block <NUM>.

At block <NUM>, the example workload analyzer <NUM> determines whether any SWL is scheduled. If so, then no IWL is to be executed so as to not interfere with the performance of the processor <NUM> when executing the SWL. Accordingly, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the armed maximum temperature (set at block <NUM>) minus the current temperature (obtained at block <NUM>) satisfies (e.g., is greater than) a threshold. Block <NUM> serves to identify situations where large temperatures drops (e.g., exceeding the threshold) occur during an active period so as to not inadvertently cause the temperature of the processor <NUM> to increase during an idle period if it has already cooled during a preceding active period. Thus, if the threshold is satisfied (e.g., the difference between the armed maximum temperature and the current temperature exceeds the threshold), control advances to block <NUM> where the example idle workload controller <NUM> disarms the IWL procedure. Thereafter, control advances to block <NUM> to determine whether to continue the process as discussed above. If the example temperature analyzer <NUM> determines, at block <NUM>, that the threshold is not satisfied, control advances directly to block <NUM> such that the IWL procedure remains armed.

Returning to block <NUM>, if the example workload analyzer <NUM> determines that no SWL is scheduled, control advances to block <NUM> where the example temperature analyzer <NUM> determines whether the current temperature is lower than the setback temperature <NUM>. In some examples, if reliability is more important than performance and the potential for large thermal fluctuations during active periods are to be avoided, blocks <NUM> and <NUM> may be omitted. In such examples, control advances from blocks <NUM> and <NUM> directly to block <NUM>. If the example temperature analyzer <NUM> determines, at block <NUM>, that the current temperature is not lower than the setback temperature <NUM>, then no action needs to be taken so control advances directly to block <NUM>. However, if the current temperature is lower than the setback temperature <NUM>, control advances to block <NUM> where the example idle workload controller <NUM> selects an IWL from the example idle workload database <NUM>. At block <NUM>, the example idle workload controller <NUM> provides the IWL to the processor <NUM> for execution. Thereafter, control advances to block <NUM>.

<FIG> is a block diagram of an example processor platform <NUM> structured to execute the instructions of <FIG> and <FIG> to implement the thermal fluctuation controller <NUM> of <FIG>. The processor platform <NUM> can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset or other wearable device, or any other type of computing device.

For example, the processor <NUM> can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor implements the example workload analyzer <NUM>, the example temperature analyzer <NUM>, the example idle workload controller <NUM>, and the example timer <NUM>.

In this example, the mass storage device implements the example memory <NUM>, and/or the example idle workload database <NUM>.

The machine executable instructions <NUM> of <FIG> and <FIG> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that example methods, apparatus and articles of manufacture have been disclosed that improve the reliability and/or useful life of a processor by reducing the frequency, number, and/or severity of large thermal fluctuations in the processor between active and idle periods of use. Furthermore, examples disclosed herein achieve this technological benefit without impacting the performance of the processor. The disclosed methods, apparatus and articles of manufacture are accordingly directed to one or more improvement(s) in the functioning of a computer.

Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture falling within the scope of the claims of this patent.

Claim 1:
An apparatus comprising:
means (<NUM>) for sensing a current temperature of a processor (<NUM>); and
means (<NUM>) for controlling an idle workload procedure, the controlling means (<NUM>) to provide an idle workload to the processor (<NUM>) to execute in response to the current temperature falling below a setback temperature,
characterised in that
the controlling means (<NUM>) is to provide the idle workload to the processor (<NUM>) when the idle workload procedure is armed and to not provide the idle workload to the processor (<NUM>) when the idle workload procedure is disarmed, and
wherein the controlling means (<NUM>) is to disarm the idle workload procedure in response to a timeout period (<NUM>) elapsing since the idle workload procedure was last armed.