This paper appears in the 2017 IGSC Workshop on Sustainability in Multi/Many-Core Systems (SiMS)

Proactive Thermal Aware Scheduling

Shehenaz Shaik and Sanjeev Baskiyar
Dept. of Computer Science and Software Engineering
Auburn University, Auburn, AL
{szs0117, baskisa}@eng.auburn.edu

Abstract—High temperatures and fluctuating temperatures temperature can be managed. The approach consists of two
decrease component reliability and lifespan. This work proposes parts: (a) anticipating when the CPU is going to be at elevated
a proactive software-based thermal aware scheduler to lower temperatures and (b) identifying the hot processes. We use
core temperature and its temperature fluctuations. It proposes
a Simple Time Derivative (STD) scheduler, which uses the two approaches to anticipate when the CPU is going to be at
time derivative of the core temperature as a predictor. Major elevated temperatures: (i) using a simple temperature threshold
heat dissipating processes can be identified by their usage of and (ii) using a Temperature Derivative Predictor (TDP) which
integer arithmetic, float operations and other CPU performance is the time derivative of the core temperature to predict the
counters. The “hot” processes are put to sleep for a short future CPU temperature. Major heat dissipating processes can
duration, if the time derivative goes above an empirically defined
threshold. This work evaluates STD using FFT, SOR, LU, and be identified by the use of integer arithmetic, float operations
Sparse benchmarks of the SciMark benchmark suite running on and other parameters as shown in [4]. If the TDP is higher than
a desktop computer. We found upto 5◦ C decrease in average/peak a predefined threshold, referred as ThresholdGradient, the hot
temperatures as compared to the baseline approach (without any processes are put to sleep for a short duration. This approach
thermal scheduling). The execution penalties only apply to the is more relevant to a system with applications whose activity
hot processes and not the whole system. For LU/Sparse the core
stayed at 35◦ C or below for 100%/82% of time with STD vs. only may cause a high rise in temperature over a relatively short
28%/19% of increase in run-time for the baseline. Furthermore, duration, e.g. applications with many floating-point operations.
for the baseline the temperature went over 40◦ C for 16% of To the best of our knowledge, this approach has not been used
run-time vs. 0% for the STD. Holding the temperature lower has before.
advantages in cooling energy reduction particularly when several
systems are running together in a room or in a server system. We The major contributions of this work are as follows:
also compared our results against Simple Threshold approach. • Proposed a software-based dynamic thermal management
STD provided lower run-time penalties and energy consumption
technique, Simple Time Derivative (STD), which uses
than the Simple Threshold strategy and marginally outperformed
in terms of temperature reduction. This research provides insight time derivatives of core temperature to predict the future
into the temperature reductions possible using a user-defined increase in temperature. Unlike the PID controller, which
software approach and the corresponding penalties on the hot slows down the entire CPU, this approach slows only
processes. The approach can be combined with air conditioning the major heat dissipating process. The approach can be
management techniques in server production systems to reduce
seamlessly integrated with PID and other hardware-based
energy consumption for any job mix where execution time is not
paramount. The reduction in temperature and its variations also thermal techniques.
increases reliability and lifespan of the CPU chip. • The approach provides a finer tuning of temperature
Index Terms—process scheduling; thermal-aware; thermal sen- at the OS level for the purpose of higher component
sors; proactive; predictor. reliability and lifespan. Space applications, where long-
term reliability and lifespan is required, are good target
I. I NTRODUCTION applications.
Based on the amount and type of activity, processor power • Implementation of Baseline (Base) and Simple Threshold
consumption produces significant heat and increase in chip (Threshold) approaches for comparison.
operating temperature. When the CPU temperature increases • Study of the impact of sleep time, TDP threshold, polling
beyond certain threshold (even at temperatures below the frequency, and activation temperature on core tempera-
hardware cut-off), it decreases chip reliability and increases tures.
cooling costs for the CPU [1]. Previous work [2] shows that • Evaluation of the proposed approaches using SciMark
the failure rate of chip doubles for every 10◦ C increase in benchmarks.
temperature. Large number of thermal cycles i.e. temporal The remainder of this paper is organized as follows. Section
fluctuations can accelerate package fatigue and plastic defor- II discusses the proposed approach, Section III the experiments
mations of chip materials, thereby causing permanent failure performed, Section IV the results and observations, Section
[3]. Thus, chip thermal management techniques can increase V the selection of parameters, Section VI assumptions and
overall component reliability and lifespan. known limitations of STD, and finally, we discuss related work
We hypothesize that by proactively scheduling the thermally in Section VII and conclusions and future work in Section
intensive processes (or “hot” processes), the rise of CPU VIII.

978-1-5386-3470-7/17/$31.00 2017
c IEEE
Algorithm 1 The STD Algorithm The implementation of scheduler was done in Java, which
Const ThresholdGradient was the language used by SciMark benchmarks as well. For
Process P all the benchmark processes, priority was set to normal. We
while true do set the benchmark parameter Resolution Default to execute
T1 ← Read core temperature each benchmark for about ten (10) minutes for the baseline
Wait δt time //Polling interval approach. CPU was left to cool before starting the next
T2 ← Read core temperature experiment. No other processes were running on system other
TDP = (T2 − T1 )/δt than basic OS processes.
if TDP > ThresholdGradient then We used on-chip core temperature sensors [8] to measure
Sleep P core temperature in Celsius at regular intervals and calculated
end if the TDP. We used Watts up PRO ES power meter to mea-
end while sure the consumption of power by CPU during execution of
benchmarks.
We compared the effect of the three different strategies on
II. A PPROACH core temperature and execution times: STD, Threshold and
We tried using regression of T and dT/dt approach to predict Base. The Base approach is when the benchmark process
the temperature. However, the historical bias introduced by the executes in the native mode.
regression was not effective for predicting the rapidly changing The threshold gradient used with STD approach and thresh-
temperature. After several trials we found a simple temperature old temperature used with Threshold approach were deter-
derivative approach to work best. mined empirically using several experiments with various
We use two approaches to reduce the CPU temperature. The configurations with an attempt to minimize core temperature
first is named the Simple Time Derivative scheduler and the with minimal impact on program execution time. In order
second is called the Simple Threshold scheduler. to find the scheduler configuration parameter values, which
In the STD scheduler, outlined in Algorithm 1, we hy- result in optimal thermal benefits, we experimented with
pothesize that using the core temperature gradient (TDP) will different polling intervals, sleep times and threshold gradient
be helpful in predicting the future temperature. It computes values. Polling interval is the period at which core temperature
the rate of change of core temperature. Core temperatures was polled using hardware sensors. When STD scheduler is
are noted at two observation points δt time apart and their used, the ThresholdGradient is the empirically determined
difference is divided by δt to get the rate of change of tem- limit which when exceeded by the observed TDP, triggers
perature or, the TDP. If the value of predictor is greater than an the process sleep for a short duration to help reduce the
empirically determined threshold gradient, the hot process is core temperature. Details of these tests and corresponding
temporarily put to sleep. In an actual implementation, the hot observations have been provided in Section V.
processes can be identified as described in [5]. This approach The threshold gradient values that we experimented with
reduces core temperature by proactively reducing processor were 2, 4, 6, 8, and 10 and the sleep times were 250ms,
activity even before the core temperature reaches hardware 500ms, 750ms, and 1s. The polling intervals experimented
threshold limit. were 100ms, 150ms, 200ms, 250ms and 500ms. The configu-
The Threshold approach reactively puts the process to sleep ration parameters, which resulted in optimum thermal benefits,
when core temperature exceeds an empirically determined were polling interval of 200ms, sleep time of 750ms and
predefined threshold temperature. threshold gradient of 4. For the Threshold approach we used
The above approaches are simple software approaches over a threshold temperature of 35◦ C. All tests were then run with
and above the hardware/kernel level approaches such as the this configuration with the benchmark activity isolated to one
PID controller/DVFS. core, using task set utility on Ubuntu.
To understand the behavior of Threshold and STD strategies,
III. E XPERIMENTS we performed several sets of tests using various benchmarks.
In order to evaluate the proposed approaches, we used We compared the results for three different strategies using
SciMark [6] benchmark suite. We selected SciMark bench- metrics of peak core temperature, average core temperature,
marks since they perform numerical calculations, which have and execution time. The average core temperature was an
a significant impact on temperature [7]. The benchmarks used average of all readings captured during benchmark execution.
were Fast Fourier Transform (FFT), Jacobi Successive Over- The peak core temperature was the maximum temperature
Relaxation (SOR), Dense Unit Factorization (LU), and Sparse observed during benchmark execution. The execution time of
Matrix Multiply (Sparse). These benchmark applications are the application was the overall time taken to complete the
floating point, memory, and integer intensive. execution of one instance of benchmark program. The results
We conducted the experiments on a Dell OptiPlex 780 with of the experiments have been shown in the graphs in the next
Intel Core 2 Duo E7600 / 3.06 GHz desktop with 4 GB RAM section. It is important to emphasize that the run-time penalties
and 320 GB HDD running Ubuntu 9.10. The room temperature are only for the hot processes and they are not system-wide
was steady at 68◦ F. penalties - indeed other processes will speed up because of
 Fig. 2. Variation of program execution time and temperature for four
benchmarks executed on a specific core with three strategies.
Fig. 1. Variation of core temperature over time with three strategies for LU
benchmark.

the sleeping of the hot processes.

IV. R ESULTS AND D ISCUSSION

A. Tests with LU benchmark
These tests were performed to understand the thermal
behavior of Threshold and STD approaches and compare them
with that of baseline.
Figure 1 depicts the change in core temperature over the
course of execution of LU benchmark for three approaches:
Base, Threshold and STD. During each test run, core tem-
perature was polled once per polling interval duration which
amounted to 3,000 measurements for each test run.
With Threshold and STD approaches, the core temperature Fig. 3. Percent of run-time that core stays within a certain range for four
reduced during process cut-off periods and the temperature benchmarks executed on a specific core with three strategies.
was observed to be less than that with baseline approach but
with a penalty on the execution time. With STD approach,
we observe that the fluctuation range of the core temperature observed with Threshold and STD strategies respectively as
is smaller than that observed with Threshold approach. The compared with the Base approach.
dips observed in temperature are the result of process being For the benchmarks tested, Figure 3 shows an overview
temporarily put to sleep. We note that, smaller fluctuations in of the percentage of duration that the CPU temperature was
temperature of a component result in longer component life in the ranges 31-35◦ C, 36-40◦ C and 41-45◦ C for the dif-
[3]. ferent strategies. We observe that with the Threshold and
STD approaches the temperature remained within 31-35◦ C for
B. Tests with one benchmark running and pinned to a core most of the time in all benchmarks. Whereas, in the Base
This set of tests were performed to understand the thermal approach, the temperature was in 36-40◦ C range for LU and
behavior of Threshold and STD approaches during execution Sparse benchmarks for most of the time. Furthermore, it never
of various benchmarks. Twelve (12) tests were executed using exceeded 40◦ C in the Threshold and STD approaches unlike
four (4) benchmarks and three (3) strategies. Core temperature the Base approach.
was polled a total of 36,000 times, once per polling interval Figure 4 shows the comparison of energy consumed, in
duration. KWH. We observe that, in spite of having near-similar
From Figure 2, we observe that in spite of executing execution run-time penalties for both Threshold and STD
the benchmarks for similar duration, the peak and average approaches, the overall energy consumed during benchmark
temperatures are different. It suggests that the applications run-time was much lower for STD during the runs of LU
contribute in different ways to the chip temperature. and Sparse. Thus STD is more efficient in controlling chip
We see that the Threshold and STD approaches suffer an temperature and thereby reduces the energy consumption by
execution time penalty ranging from 0-53% and 0-44% as reduced usage of fan. When a mix of applications is running,
compared with the Base approach. The penalty is due to the it is likely that the net power usage will be smaller as the cool
use of sleep times to reduce chip temperature. jobs will be able to complete during the sleep periods of the
A reduction of 0-5◦ C and 0-4◦ C in average core temper- hot jobs. Furthermore air-conditioning costs (not accounted for
atures and 0-6◦ C and 0-5◦ C in peak core temperatures was here) will be lower, given that the temperature is lower.
Fig. 4. Variation of energy consumption by CPU for four benchmarks Fig. 6. Variation of program execution time and core temperature for various
executed on a specific core with three strategies. threshold gradients and sleep times with STD strategy for LU.

Smaller polling intervals help notice the rise in temperature

early so that an appropriate action can be taken early by the
scheduler to control further rise in core temperature. From
the test results in Figure 5, we observe that as the polling
interval increases beyond 200ms, the scheduler is less effective
in controlling the average and peak temperatures, as the rise in
temperature was not detected early enough. Core temperature
is observed to be lower at lower polling intervals.

B. Effect of Threshold Gradient

Tests were conducted for threshold gradient values of 2,
Fig. 5. Variation of program execution time and core temperature for various
polling intervals and sleep times with STD strategy for LU. 4, 6, 8 and 10. Each of these tests was repeated for sleep
durations of 250ms, 500ms, 750ms, and 1sec. Twenty four
(24) tests were executed using six (6) threshold gradients and
V. S ELECTION OF PARAMETERS four (4) sleep times. Core temperature was polled a total of
Tests were executed with the LU benchmark to observe 72,000 times.
its impact on system performance with different values for From the test results in Figure 6, we observed that, as
parameters: polling interval, threshold gradient, threshold tem- the threshold gradient value increases beyond 4, scheduler
perature, activation temperature, and sleep time. LU bench- is less effective in controlling the average and peak core
mark was selected to execute these set of tests as its activity temperatures, as the rise in temperature is not detected early
produces most changes in core temperature as compared to enough. Core temperatures were lower at lower threshold
other benchmarks. Future work will use all the benchmarks to gradients.
finally select these parameters. For specific applications, one
C. Effect of Activation Temperature
can select parameters based on that application.
At lower chip temperatures, there may not be a risk of Tests were executed for activation temperatures of 25, 30,
running into sudden rise to temperature high enough to affect 35, 40, 45, and 50. Seven (7) tests were executed using seven
the chip. Hence, the penalty of STD scheduler on system (7) activation temperatures. Core temperature was polled a
performance can be reduced by enabling it only when the total of 21,000 times.
chip temperature is sufficiently high such that there is a need Higher activation temperature helps in minimizing program
to control it. Activation temperature is the temperature limit execution time by reducing the number of instances of process
above which STD will be enabled by scheduler. cut-off, but may cause an increase in core temperature. From
During test execution, core temperature is polled once per the test results in Figure 7, we observe that, when the activation
polling interval duration. Overhead of polling core tempera- temperature is 40◦ C or more, STD is not activated by scheduler
tures was same for all the three approaches. The corresponding often enough to control the core temperature.
results have been graphically displayed and discussed next. From the experiments, we observe that applications react
differently to various thermal aware scheduling approaches,
A. Effect of Polling Interval perhaps due to the different thermal profiles of programs. For
Twenty (20) tests were executed using five (5) polling example, thermal improvements were observed for the LU
intervals and four (4) sleep times. Core temperature was polled benchmark using Threshold and STD schedulers, whereas none
a total of 16,600 times. was observed for SOR.
 sets the power gating and clock gating of the peripherals and
components. Computational Sprinting uses [13] higher speed
clocks for short bursts of time to reduce the net battery usage.
Ayoub and Rosing [1] created a temperature predictor utilizing
band-limited property of the temperature-frequency spectrum
and is workload-independent. All the above approaches to
chip thermal management do not consider the thermal impact
generated by individual applications and thereby result in
penalizing all the active applications in system by modifying
the chip voltage and/or frequency.
Coskun et al. [14] used integer linear programming ap-
proach to obtain a task schedule for MPSoC that meets real-
Fig. 7. Temperature and Execution time for various activation temperatures time task deadlines while minimizing thermal hot spots and
with STD approach for LU.
spatial temperature differentials across the chip. Fisher et al.
[15] proposed solution for thermal aware scheduling problem
VI. L IMITATIONS for sporadic real time tasks in a homogeneous multicore
system. Chuan et al. [16] developed a patterns based approach
From the experiments, the observed maximum temperature for energy-efficient scheduling to reduce leakage energy in
was 56◦ C, whereas the system critical temperature was 100◦ C. CPUs and thus reduce temperature. These solutions require
However, as we noted earlier, each 10◦ C reduction in temper- prior knowledge of workload and cannot accommodate any
ature causes the failure rate of the chip to be cut in half. Thus dynamic changes at runtime, thus limiting their applicability
reduction in temperature even around 50◦ C are important. in generic environments.
Core temperatures were probed using lm-sensors utility Weissel and Bellosa [17] throttled processes, local and dis-
and hence the current solution is limited by the granularity tributed, to reduce power consumption, and thereby processor
of updates provided by lm-sensors. However, the utility lm- temperature, by setting limits to energy containers towards
sensors takes only 6-10ms, which is very small compared to rate of energy consumption. Merkel, Bellosa and Weissel [18]
the polling intervals and sleep times. proposed energy-aware scheduling policies considering the
Scheduler is currently implemented in user space, rather tasks` energy profiles to distribute energy consumption evenly
than kernel space. Hence, benchmark processes are put to sleep among CPUs. These solutions are designed to control chip
for a short duration to contain the core temperature. When temperature by limiting power/energy consumption of tasks.
the approach is implemented as part of an operating system But a more direct approach is preferable which considers the
scheduler, process priority and time slice need to be changed chip temperature to control its thermal effects in chip.
rather than explicitly letting the process to sleep for a specific Jin and Maskell [19] proposed an event-driven thermal
duration. As the scheduling decisions are made for each epoch, estimation method based on system level events. A thermal
we anticipate that the improved granularity of polling will help map records the temperature of all cores and is updated each
reduce program execution time overhead. time an atomic power event occurs. Kumar et al. [4] developed
a regression-based thermal model for prediction of proces-
VII. R ELATED WORK
sor temperature using hardware performance counters. They
Sheikh et al. [9] provided a formal description of the thermal proposed a thermal aware scheduler which characterizes the
aware job-scheduling problem along with a brief survey of thermal contribution of running processes and modifies their
various hardware and software solutions. The majority of time-slice and priority to contain chip temperature within limit.
techniques used to reduce chip temperature are reactive. Such The two approaches discussed here schedule the processes
techniques have used strategies such as dynamic voltage based on the thermal impact of their activity to chip. But for
and frequency scaling (DVFS), dynamic power management accurate results, they require calculation of statistics at regular
(DPM), dynamic thermal management (DTM), leakage energy intervals and continual update of parameters, which introduces
and variability aware thermal management. However, some of additional compute and storage overhead.
these approaches resulted in thermal emergencies due to sud- Anupindi [20] proposed a process-based proactive thermal
den spikes in chip temperature, which could cause irreversible aware scheduler using derivative of floating point operations,
damage to the chip. memory accesses and CPU chip temperature. The regression-
Intel uses a Proportional-Integral-Derivative (PID) con- based approach is not feasible for practical implementations
troller [10] to ensure that the CPU chips operate below due to high time complexity and overhead of regression
critical temperature. AMD [11] used task migration to coolest calculations.
core along with coarse and fine-grained controls such as p-
states, and turn-off registers to save energy. ARM uses kernel VIII. C ONCLUSIONS AND F UTURE WORK
thermal framework [12] to register thermal zones and cooling In this paper, we have proposed a thermal aware process
devices for reducing temperature. Kernel thermal framework scheduling approach, Simple Time Derivative (STD). We im-
plemented it in user space and evaluated the performance using [5] W. Liu and A. Nannarelli, “Temperature aware power optimization for
SciMark benchmarks (FFT, SOR, LU, and Sparse) against the multicore floating-point units,” in Conference Record of the Forty Fourth
Asilomar Conference on Signals, Systems and Computers, Nov 2010, pp.
Threshold and Baseline approaches. 1134–1138.
We ran several experiments to observe the impact of various [6] B. Miller and R. Pozo, “Scimark 2.0,” Mar 2004 (Accessed 25 Jan
scheduler configuration parameters such as activation tem- 2015). [Online]. Available: http://math.nist.gov/scimark2
[7] E. Kursun, C.-y. Cher, A. Buyuktosunoglu, and P. Bose, “Investigating
perature, sleep time, polling interval and threshold gradient. the effects of task scheduling on thermal behavior,” in Third Workshop
The evaluation metrics were execution time, average core on Temperature-Aware Computer Systems, Boston, MA, Jun 2006, pp.
temperature, peak core temperature, and percent of time the 1–12.
[8] “lm-sensors,” 2009 (Accessed 25 Jan 2015). [Online]. Available:
core stays within a certain temperature range over the duration http://www.lm-sensors.org
of program execution. [9] H. F. Sheikh, I. Ahmad, Z. Wang, and S. Ranka, “An overview and
We found that STD can successfully contain the core classification of thermal-aware scheduling techniques for multi-core
processing systems,” Sustainable Computing: Informatics and Systems,
temperature as compared to the Baseline approach and it vol. 2, pp. 151–169, 2012.
marginally outperformed the Threshold strategy. Furthermore, [10] “Mechanical and thermal design considerations,” Jun
the duration for which the core stayed at higher temperatures 2009 (Accessed 25 Jan 2015). [Online]. Available:
http://download.intel.com/design/processor/designex/317804.pdf
was substantially lower for STD. In addition, it resulted in [11] “AMD Athalon features,” Sep 2012 (Accessed 25 Jan 2015). [Online].
a substantially smaller temporal fluctuation range, which is Available: http://www.amd.com/us/products/desktop/processors/athlon-
beneficial for chip reliability and improved lifespan. Execution ii-x2/Pages/athlon-ii-key-features.aspx
[12] “Linux,” Sep 2012 (Accessed 25 Jan 2015). [Online]. Available:
of benchmarks using STD approach resulted in significantly http://elinux.org/images/2/2b/A New Simplified Thermal Framework
smaller energy consumption as compared to that with Thresh- For ARM Platforms.pdf
old or Baseline approaches. [13] A. Raghavan, Y. Luo, A. Chandawalla, M. Papaefthymiou, K. P.
Pipe, T. F. Wenisch, and M. K. Martin, “Computational sprinting,” in
In addition to the tests discussed in this paper, we have Proceedings of the 18th Symposium on High Performance Computer
tested the impact of proposed approach for scenarios such as Architecture, Feb 2012, pp. 1–12.
single benchmark running but not pinned to any specific core, [14] A. K. Coskun, T. S. Rosing, K. A. Whisnant, and K. C. Gross,
“Temperature-aware MPSoC scheduling for reducing hot spots and gra-
and multiple benchmarks concurrently running in the system. dients,” in Proceedings of the 13th Asia South Pacific Design Automation
We have observed similar behavior of proposed approach Conference, Seoul, Korea, Mar 2008, pp. 49–54.
in these scenarios as well. The corresponding results are [15] N. Fisher, J. Chen, S. Wang, and L. Thiele, “Thermal-aware global real-
time scheduling on multicore systems,” in 15th IEEE Real-Time and
eliminated in this paper due to space limitations. Embedded Technology and Applications Symposium, April 2009, pp.
The results discussed in this paper were from the exper- 131–140.
iments performed on a desktop machine. We anticipate that [16] C. Yang, J. Chen, L. Thiele, and T. Kuo, “Energy-efficient real-time task
scheduling with temperature-dependent leakage,” in Design, Automation
the benefits of the STD scheduler will be more pronounced on and Test in Europe, Dresden, Germany, Mar 2010, pp. 9–14.
laptops and hand-held devices, which run on battery and may [17] A. Weissel and F. Bellosa, “Dynamic thermal management for dis-
not have a built-in fan to reduce chip temperature. tributed systems,” in Proceedings of the First Workshop on Temperature-
aware Computer Systems, Jun 2004.
Future work will involve conducting experiments on laptops [18] A. Merkel, F. Bellosa, and A. Weissel, “Eventdriven thermal manage-
and hand-held devices, using the SPEC benchmark suite, and ment in SMP systems,” in Second Workshop on Temperature-Aware
integrating the approaches into the Linux scheduler. Also, Computer Systems, Madison, USA, 2005.
[19] J. Cui and D. L. Maskell, “High level event driven thermal estimation
instead of using sleep states we would change the time slices for thermal aware task allocation and scheduling,” in Asia and South
and priorities of the processes and/or migrate the process to Pacific Design Automation Conference, Jan 2010, pp. 793–798.
cooler cores resulting in smaller run-time overheads. [20] S. S. Anupindi, “Proactive thermal-aware scheduling,” Ph.D. disserta-
tion, Auburn University, Auburn, AL, Dec 2014.
ACKNOWLEDGMENTS
We thank S. S. Anupindi for preliminary version of software
and test environment. We also thank Dr. Adit Singh for the
guidance and feedback provided on test results.
R EFERENCES
[1] R. Ayoub and T. Rosing, “Predict and act: dynamic thermal management
for multi-core processors,” in Proceedings of ACM/IEEE International
Symposium on Low Power Electronics and Design, San Francisco, CA,
2009, pp. 99–104.
[2] C. J. Lasance, “Thermally driven reliability issues in microelec-
tronic systems: status-quo and challenges,” Microelectronics Reliability,
vol. 43, no. 12, pp. 1969–1974, Dec 2003.
[3] Simunic, T., M. Kresimir, and G. De Micheli, “Optimization of reliabil-
ity and power consumption in systems on a chip,” in Proceedings of the
International Workshop on Power and Timing Modeling, Optimization
and Simulation, Leuven, Belgium, Sep 2005, pp. 237–246.
[4] A. Kumar, L. Shang, L. Peh, and N. K. Jha, “System-level dynamic ther-
mal management for high-performance microprocessors,” IEEE Trans-
actions on Computer-aided Design of Integrated Circuits and Systems,
vol. 27, no. 1, pp. 96–108, 2008.