热裕度保持方案提升多媒体QoS

原创于 2025-10-29 04:43:13 发布 · 670 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#热裕度 #动态热管理 #异构多核 #QoS #温度控制

一种用于交互式多媒体消费电子产品的热裕度保持方案

N. 巴达诺、Y. Woo、J. Hwang 和 E. Seo

摘要

异构多核架构被认为是满足下一代媒体格式（如超高分辨率、3D或全息技术）处理性能需求的有效解决方案。然而，异构多核处理器中的性能核心会散发大量热量。为了应对热风险，大多数现代嵌入式处理器提供了动态热管理（DTM）功能，该功能会强制降低处理器的时钟频率。尽管这种简单的方法可以将系统温度维持在热触发点以下，但当热危机主要由非优先级应用引起时，优先级多媒体或交互式应用的性能仍会因性能下降而受到显著影响。本文提出了一种名为热裕度保持（TMP）的新型动态热管理方案。TMP为优先级应用程序和非优先级应用程序设置不同的热触发点，从而形成热裕度，即两个触发点之间的温度差。在所提出的方案下，通过仅牺牲非优先级应用的性能，优先级应用可以在热裕度内运行而不受任何干扰。评估结果表明，在高温条件下，该方案显著降低了视频播放的服务质量下降。

索引术语 — 动态热管理，温度，热模型，异构多核

一、引言

下一代多媒体格式（如3D、超高清或全息技术视频）在处理时需要极高的性能。此外，第三方应用程序的数量正在迅速增加，这些应用程序通常对性能要求很高。与此同时，能效和功耗问题日益重要。

异构多核架构将高性能核心和能效核心集成在同一芯片上，被认为是突破消费电子产品中嵌入式处理器上述对立需求的有前景的解决方案。

异构多核处理器中的高性能核心通常采用乱序架构，为了实现高性能，其功耗远高于普通的嵌入式处理器。因此，高性能核心的长期运行会散发大量热量，累积的热量将导致系统出现热危机。

然而，与可以轻松容纳大型散热片或多风扇的PC或服务器系统不同，消费类电子设备中所采用的散热解决方案的散热能力由于设计外形因素和制造成本的严格限制而十分有限。因此，对于采用异构多核处理器的消费电子产品而言，热管理是一个重要问题。

为了解决热问题，大多数现代嵌入式处理器都配备了动态热管理（DTM）方案，当系统温度超过预设的热触发点时，通过动态电压频率调节（DVFS）降低时钟频率。这种简单直接的方法能够轻松控制系统温度，防止其超过热触发点。然而，传统的动态热管理方案常常无法保持交互式或多媒體应用的服务质量（QoS）。

具有时效性要求的工作负载（如多媒体播放器或游戏）在CPU利用率[1]方面表现出高度动态性。为了维持目标服务质量（QoS），例如上述应用中的帧率，它们会间歇性地出现高强度的CPU执行阶段。传统的动态热管理方案（DTM）会盲目降低所有进程的执行速度，包括多媒体或交互式工作负载[2]，即使大部分累积的热量是由云备份、病毒扫描等长期后台任务产生的。

为应对消费电子产品的热风险，本文提出了一种新型的动态热管理方案——热裕度保持（TMP）。TMP引入了热裕度的概念，该热裕度定义为软件定义的热触发点与非优先级任务之间的差值，该热触发点被施加于非优先级应用程序以及硬件供应商允许的最高温度。TMP允许优先级应用程序（例如前台交互式应用程序）在无性能下降的情况下执行，而当当前温度介于这两个热极限之间时，非优先级应用程序的执行将受到控制以降低系统温度。因此，在所提出的方案下，优先级应用程序的服务质量在大多数情况下几乎不会受到热管理的影响。

所提出的方案在一种常用于智能手机和智能电视的嵌入式系统上实现。通过原型实现评估了在高温条件下服务质量的提升情况。

本文的其余部分组织如下。第二节阐述了本研究的动机。基于此动机，第三节提出了TMP方案。第四节描述了所提出方案的原型实现，并展示了评估结果。在第五节介绍相关工作后，第六节总结了本研究并讨论了进一步的研究方向。

II. 动机

现有的动态热管理（DTM）定义了针对预设温度水平的适当响应，并根据当前温度执行相应操作。该机制可以在片上系统（SoC）的固件中实现。然而，在许多情况下，动态热管理（DTM）是在操作系统（OS）内核的热管理驱动模块中实现的。

本研究中使用的嵌入式系统展示了典型的动态热管理（DTM）实现。该嵌入式开发板的内核热驱动程序定义了三个温度级别及其相应的降温策略，如表I所示。

温度 (°C)	策略
110	时钟频率调节
115	通知
120	切断CPU执行

当当前温度超过110摄氏度时，驱动程序在一个循环中每隔几毫秒采样一次温度，并根据以下规则调整时钟频率：i) 如果当前温度高于触发点且温度正在上升，则驱动程序将CPU时钟频率降低一个级别。ii) 如果当前温度低于触发点且温度正在下降，则驱动程序提高时钟频率。

在115摄氏度时，热管理单元（TMU）通知操作系统内核进入临界状态，而在120摄氏度时，TMU会强制关闭处理器。因此，操作系统应将时钟频率调节点视为系统温度的实际上限。

该机制被视为针对当前温度状态的简单动态电压频率调节响应。它不了解正在执行的线程的性质，无论其是否有时效性要求，且不关心用户体验如何受到性能下降的影响。

为了确定热管理方案对交互式应用的性能影响，监控了多种系统参数（如系统温度、时钟频率和处理器利用率），这些参数是在执行两个应用程序期间采集的，这两个应用程序在第四节中有详细描述，分别代表高优先级前台任务和后台任务。

本研究选择的目标系统代表了一种典型的异构多核架构，这种架构如前所述被消费类电子设备广泛使用。在目标系统中，四个性能核心被分组为性能核心簇，而另外四个能效核心被分组为能效核心簇。在任何时刻，性能核心簇或能效核心簇中的任意一个都可以被激活，电源管理模块将决定哪个簇运行。

频率（GHz）
1.6 GHz, 1.5 GHz, 1.4 GHz, 1.3 GHz, 1.2 GHz, 1.1 GHz, 1.0 GHz, 0.9 GHz, 0.8 GHz

如表 II 所示，处理器在内核中为电源管理模块提供了多个时钟级别。能效核心簇的最高工作时钟频率为 1.2 GHz，性能核心簇的最高工作时钟频率为 1.6 GHz。当电源管理模块将时钟频率调整至高于 1.2 GHz 的值时，性能核心簇将被激活，而节能核心簇将运行。例如，当电源管理模块将目标工作时钟频率从 1.2 GHz 提升至 1.3 GHz 时，性能核心簇中的核心将退出睡眠状态并在 1.3 GHz 下运行，而原本以 1.2 GHz 运行的节能核心簇中的核心则将进入睡眠状态。

示意图0

如图 1 所示，由于热危机，时钟频率下降五级或更多级是常见现象。这种激进的降频将导致处理器利用率饱和。即使在处理器利用率已饱和且优先级任务未获得足够处理器资源的情况下，后台任务仍消耗了大量处理器资源，如图 1 所示。

交互式或多媒體应用，例如遊戲、網頁瀏覽器和多媒體回放器，由於在很大程度上依賴於人機交互和輸入數據，因此在任何給定時間的性能需求都極不可預測。因此，交互式工作負載具有需要高處理能力的間歇性執行階段，這被稱為高性能突发。

示意图1

如果交互式任务是导致热危机的主要原因，那么减缓其执行将是一种合理且不可避免的解决方案。然而，在许多情况下，高温是由执行长期后台任务所引起的热量积聚造成的。在这种情况下，优先级任务的高性能突发可能仅是导致用户可感知的服务质量下降的微小但最终的因素，如图2的问题场景所示。

显然，期望能够保护优先级任务的服务质量（QoS）不受非优先级任务散发的热量所导致的性能降频的影响。

如果动态热管理方案（DTM scheme）能够预测优先级应用程序间歇性激活所带来的温度上升，并能将系统温度维持在某一阈值以下（该阈值将根据预测结果确定，如图2 的期望场景所示），则可实现这一目标。

III. 热裕度方案设计

TMP方案的设计目标是保持热裕度，即使在优先级任务发生高性能突发时，也能确保温度不会达到热触发点。

与传统DTM机制被动响应当前温度不同，TMP采用主动方法。因此，TMP可与传统DTM结合使用。在这种情况下，传统DTM作为保护机制，将在温度超过硬件定义的热触发点的灾难性情况下，通过急剧调整时钟频率来响应。

示意图2

图3展示了TMP方案的基本工作流程。需要一个热模型来预测由于优先级任务的高性能突发所散发的热量导致当前温度上升的程度。构建的模型将用于确定系统在热管理方面是否处于安全状态。当确定系统处于危险状态时，TMP会限制非优先级或非交互式线程的执行，这些线程不会影响用户体验。因此，TMP包含了一项技术，用于从系统中所有现有线程中识别交互式线程。最后，TMP提供降温策略，并根据具体情况选择其中之一，以便在保持优先级应用程序性能的同时控制系统温度。

以下小节详细介绍了TMP的引入组件。

A. 热模型

TMP 的主要贡献之一在于其预测性。使 TMP 能够预测温度变化的是片上系统（SoC）的热趋势模型。热模型本质上是一条温度随时间变化的曲线，该曲线取决于多种因素，包括处理器负载、时钟频率、活动核心数量、处理器温度以及环境温度。借助这条温度变化曲线，TMP 能够预测未来的温度值。

热模型由模型构建器进程构建，且应在首次启动和任何系统重新配置期间构造该模型。模型构建器在执行一系列压力测试的同时收集构建模型所需的数据。在测试运行期间，模型构建器会在所有可能的核心配置下执行压力测试。模型构建器记录温度读数随时间的变化，并根据时间变化推导出给定核心配置下的温度曲线。

片上温度传感器可能存在几度的不确定性。然而，该模型并非用于估计绝对温度，而是用于预测相对于热极限的相对温度距离，而热极限同样由片上温度传感器确定。此外，该模型基于大量收集的温度数据构建。因此，温度传感器的不准确性对模型的有效性影响甚微。

环境温度会影响系统散发产生热量的速度。因此，它决定了系统的维持温度和温度变化速度。尽管大多数现代嵌入式处理器都配备了处理器温度传感器，但很少配备环境温度传感器。因此，温度模型通过测试运行结果间接推断环境温度。如果环境温度发生剧烈变化，则应重新建立模型。然而，观察表明，环境温度的微小变化（例如 10°C）对模型的准确性影响可以忽略不计。

采用该方法构建的模型的R²值为0.998，该值用于衡量模型对观测数据的拟合程度，表明曲线具有高准确性。许多现有的研究成果[2],[3]提出了类似的方法或观察结果。

TMP基于构建的热模型，预测在当前核心配置下达到热触发点的预计到达时间（ETA）。为了降低内核在预测 ETA时的开销，TMP根据热模型创建ETA表并将其存储在内核内部。由于温度粒度为1摄氏度，这些表在实验系统中仅占用几KB空间。

每个ETA表代表特定核心配置的热趋势曲线；例如，四个在1.5 GHz下运行的性能核心。表中的条目由当前温度索引，并包含在热极限下的计算的ETA。

B. 交互式线程识别

交互式线程是指影响用户体验的线程。应用程序典型的刺激‐反应循环由多个协同工作的交互线程组成，这一系列交互线程必须在人类感知阈值（通常为50毫秒[4]）内完成该循环。因此，TMP必须清楚哪些线程是优先级较高的线程。

TMP 会检测交互式线程，并将其放入交互式线程组，如下所示。

首先，通过平台的输入框架检测到用户输入，例如屏幕触摸或按键操作。负责处理此输入事件的线程将被放入交互式线程组中。然后，系统会监控属于交互式线程组的任何线程与该组之外的其他线程之间的进程间通信（IPC）机制。当检测到通信时，TMP 会将非交互对应线程标记为交互式线程，并将其加入交互式线程组。

最终结果是一组线程，这些线程的成员在特定时刻直接或间接地影响用户体验。TMP 将交互式组中的线程视为高优先级线程。

C. 调度动态

TMP 在每个 10毫秒间隔监控仅由交互式线程贡献的处理器利用率、活动核心数量、时钟频率和当前处理器温度，以确定达到热触发点时的预计到达时间（ETA），并确定适当的冷却策略。该 10毫秒间隔的监控也被 ondemand 调节器 [5] 所采用，后者是 Linux内核默认的电源管理模块，并已验证其开销可忽略不计。

TMP 机制定义了三种热状态，如图4所示，系统在任意时刻都将处于其中一种状态。这些状态的基本描述如下：
- 安全状态：无热危机，满负荷运行。
- 报警状态：热危机即将发生，采取预防措施。
- 危险状态：正在进行的热危机，评估情况并在必要时采取进一步措施。

示意图3

当系统处于安全状态时，TMP会定期检查温度变化。如果温度正在上升，则TMP会根据热模型判断预计到达时间（ETA）是否大于热裕度，该热裕度为每个线程组记录的最长突发周期之和。

如果TMP检测到在当前核心配置下到达触发点的预计到达时间（ETA）短于热裕度，则系统进入报警状态。报警状态是一种过渡状态，在此状态下，系统会应用新的冷却策略并转向危险状态。根据具体情况，用于逆转或缓解温度变化的适当冷却策略可能有所不同。第三节.C讨论了降温策略的详细信息。

一旦应用了冷却策略，TMP 将进入危险状态。在此状态下，TMP 会在每个监控间隔评估在报警状态时所应用的冷却策略的影响。由于冷却策略改变了核心配置，TMP 会选择反映当前核心配置的相应预计到达时间表。

如图5所示，被监控的系统状态在危险状态时有四种可能的情况。

S1) 温度仍在上升，且预计到达时间（ETA）短于确定的热裕度。
S2) 温度仍在上升，但预计到达时间（ETA）长于确定的热裕度。
S3) 温度正在下降，但在最大性能水平下的预计到达时间（ETA）仍短于确定的热裕度。
S4) 温度正在下降，且即使在最大性能水平下，预计到达时间（ETA）也长于确定的热裕度。

示意图4

D. 冷却策略

示意图5

图6展示了冷却决策启发式方法的输入和输出概览。它将获取之前所述由TMP在数据采样实例中分析得到的系统状态值，应用决策启发式来选择适当的冷却策略，并根据所选策略创建适合当前情况的新核心配置。

漏电功耗对目标系统的总散热有显著贡献；例如，在目标系统中约占35%。然而，漏电功耗几乎无法控制。因此，降温主要通过调节动态功耗来实现。

有两种替代策略可以降低系统温度：减少活动核心数量和降低时钟频率。尽管这两种方法都会显著减少散热，但降低时钟频率会延缓所有线程的执行，而减少活动核心数量则不会。

活动核心数量将剥夺低优先级线程被调度的机会。在应用冷却策略之前，非优先级线程的调度优先级会被调整到最低级别，而高优先级线程的调度优先级则被调整到最高级别，以便在可能的情况下，非优先级线程让出处理器资源给高优先级线程。

TMP 的第一个启发式策略是减少活动核心数量，因为与另一种选择相比，高优先级线程的执行时间更不容易发生变化。确定能够安全维持系统温度同时最小化对执行时间影响的活动核心数量的最佳平衡点在技术上具有挑战性。为了简化这一问题，TMP 会逐个关闭核心，直到交互式线程的数量大于或等于活动核心数量的两倍为止。其背后的原理在于，每个核心少于两个线程将无法充分利用现代处理器架构中的超标量、乱序执行和同时多线程（SMT）能力，而每个核心超过两个线程则可能在核心内部产生显著的资源争用。然而，每核心合适的线程数量可能因工作负载特征和处理器微架构的不同而有所差异。

当活动核心数量等于交互式线程数量的两倍时，将应用第二个启发式方法，该方法会将时钟频率降低一级。

然而，如果交互式线程带来的处理器利用率上升超过预定义阈值（例如70%），TMP既不会降低时钟频率，也不会减少活动核心数量。TMP还将维持当前核心配置，因为饱和的处理器利用率会导致交互式应用的延迟响应。

值得注意的是，这些启发式方法较为简单，在算法本身以及利用新型架构提供的新兴硬件能力方面都有很大的改进空间。例如，本研究中使用的嵌入式系统由于两个核心簇之间的缓存一致性保护存在困难，只能激活节能核心簇或高性能核心簇中的一个，而不能同时运行两者。然而，前沿异构多核架构已克服了这一限制，能够同时运行两个核心簇[6]。借助该技术，TMP可以将非优先级线程迁移到能效核心，同时将高优先级线程保留在性能核心，以降低系统温度。

E. QoS看门狗

到目前为止，已经描述了创建热裕度和保持优先级应用程序性能的策略。当然，在实际情况中，热高效核心配置不可能无限期地持续下去。在某个时间点，工作负载将需要增加处理能力。换句话说，正如之前所定义的那样，零星的高性能突发可能在任何时候毫无预警地发生。因此，TMP还需要一种机制来检测这些高性能突发，并改变核心配置以满足新增加的处理需求。这就是QoS看门狗发挥作用的地方。

服务质量看门狗是TMP中最后一个但并非最不重要的组件。如图7所示，看门狗组件会定期采样交互式线程的处理器利用率。如果达到预定义阈值，则TMP将采用与启发式算法相反的方式，将处理器性能提高一个级别以确定冷却策略。服务质量看门狗的处理器利用率阈值可能不同于用于冷却策略确定算法的阈值，并且建议设置得更高。在评估中，服务质量看门狗的阈值被设置为80%。

示意图6

此时，TMP有两个相互对立的组件在争夺利益。一方面，冷却决策组件倾向于降低处理器性能；另一方面，QoS看门狗则推动提升处理器性能。当可能时，这两种力量将共同作用以达到所需的平衡。图8所示的状态图解释了这两个对立组件如何同时协同工作。

示意图7

F. 局限性

确定热裕度的最佳大小对于TMP的理想运行是可取的，因为过大的热裕度会降低后台工作负载的性能，而过小的热裕度可能导致热危机。找到热裕度的最佳大小意味着该机制需要预先知道给定交互式工作负载中高性能突发的持续时间，而这实际上是不可能的。由于这一点，当前的TMP实现试图构建最大的可能余量，通过累加每个交互式线程组的最长突发周期来实现。显然，这种方法会对后台工作负载的性能产生不利影响。

然而，通过深入分析工作负载行为可以解决这一问题。例如，TMP 可以采用统计方法来估计给定应用程序的可接受热裕度水平。此外，为了推导出最优热裕度，TMP 可以精确模拟当多个交互式线程组竞争处理器资源时，整个处理器突发周期将发生的情况。关于热裕度确定的研究超出了本文的范围，本文提出并实现了基于工作负载特征的差异化热管理概念，该研究方向将留作未来的研究课题。

IV. 评估

为了评估TMP在维持交互式应用用户体验方面的有效性，进行了一项对比实验。该实验将TMP与开箱即用的动态热管理（DTM）以及为目标嵌入式系统构建的Linux发行版中包含的电源管理机制进行了比较。

对于工作负载，模拟了一种能够对处理器施加足够压力以达到高温的场景。此外，该场景还代表了现代消费电子设备（如智能手机、智能电视或平板电脑）的一种可能的常见用例。

工作负载由两个同时运行的应用程序组成，即后台应用程序和前台应用程序，如表III所述。后台任务模拟了长期的计算密集型应用程序，例如后台文件加密、恶意软件检测的模式匹配、内存去重扫描、3D数据处理、多媒体文件编码等。随着消费电子产品的功能和特性的扩展，此类后台任务的类型有望增加。创建并执行了三个计算工作负载实例以使四个核心均达到压力状态。

工作负载	类型	描述
视频播放器	交互式	1080p/29.97 fps 文件的视频播放
计算	后台	SPEC2006基准测试

作为前台多媒体工作负载的一个代表性示例，选择了视频播放器，因为其服务质量下降易于进行定量测量，可通过帧跳过来体现。另一方面，尽管对多种视频游戏进行的实验明显显示出应用TMP带来了感官服务质量提升，但要对其他交互式应用（如游戏或网页浏览器）的服务质量进行定量测量在技术上较为困难。

为视频播放器创建了六个线程并执行，以满足视频播放的处理需求。根据要渲染的帧的特性，性能波动显著。例如，渲染快速移动的场景比渲染静态场景需要更高的性能。因此，如前所述，高性能突发会 sporadically 出现，且其持续时间难以预测。

工作负载的混合在第二节中介绍的目标系统上执行。为了进行比较，首先在未修改的Linux内核上运行这些工作负载，该内核包含ondemand电源管理模块和默认动态热管理模块（在第二节中已说明）。然后，在启用了TMP的Linux内核上运行这些工作负载。为防止与TMP产生干扰，ondemand电源管理模块被禁用。每个工作负载运行两分钟，并在充分冷却开发板后多次重复实验。本文展示的时间序列图是从多次重复实验中选取的，以体现典型特征。

示意图8

为了定量衡量用户体验下降情况，从视频播放器收集了调试数据。当处理能力不可用时，视频渲染软件会跳过部分视频帧。这将导致帧率变慢和视频质量下降，两者均直接影响用户体验。调试数据会显示在任意时刻视频渲染器跳过的视频帧所对应的毫秒数。

图9显示了实验前90秒内跳帧持续时间的时间序列。每条垂直线代表未能及时渲染帧的持续时间。超过50毫秒的跳帧明显可察觉，而超过100毫秒的跳帧则会显著影响观看体验。

结果显示，默认DTM产生了大量的跳帧现象，且每次跳帧的持续时间明显较长。在两分钟的视频播放过程中，帧跳过的总持续时间平均为7,491 毫秒。然而，TMP显著抑制了跳帧的发生频率和严重程度，使帧跳过总时长降低至1,439 毫秒。

不幸的是，即使使用TMP也无法完全消除帧跳过，某些实例甚至达到了100毫秒。这是因为实验中的热裕度未被确定为足够大；因此，QoS看门狗的性能提升决策被冷却策略所抵消。

默认DTM导致的严重性能下降可归因于其激进的性能调整。当频率低于1.4吉赫时，视频播放器开始出现帧跳过。然而，如图1所示，默认DTM下时钟频率很容易降至1.4吉赫以下。相比之下，TMP在大多数情况下避免了帧跳过，因为它创造了更合适的热环境，使视频播放器能够使用所需的全部处理能力，从而在不影响系统的情况下提高了温度。

示意图9

图10 显示了两种实验配置下的系统温度变化时间序列。环境温度设置为 25 °C。TMP 创建的前三个热裕度在图10(b)中标记为 M1、M2 和 M3。在 M1 时，TMP 决定将核心数量减少至三，如图11 所示，这减缓了温度上升。然而，温度持续上升至报警状态，在 M2 时，由于存在六个交互式线程，TMP 选择将时钟频率降低一个级别，而不是停用一个核心。在 M3 时，TMP 再次将时钟频率降低一级，M3 之后温度在约 107 °C 左右波动。

系统使用TMP时很少达到热极限，而默认DTM则频繁触及热极限。由于TMP对温度变化的主动响应，与默认DTM相比，TMP还明显降低了温度变化幅度。

尽管降低平均温度不是TMP的目标，但它在一定程度上降低了平均工作温度。默认DTM方案设法将给定工作负载的平均温度保持在108 °C，视频渲染跳过总时长为 7,491 毫秒。在TMP下的平均温度为106.5 °C，表明热量积聚减少了1.8%。

最重要的是，TMP 仅累积了 1,439 毫秒的跳过视频渲染时间，代表服务质量提高了 80.8%。尽管平均散热减少可能并不显著，但 TMP 的主要关注点——服务质量的提升——是显著的。

示意图10

图11 显示了温度变化、交互式线程处理器利用率、时钟频率和活动核心数量的时间序列。时钟频率保持在 1.3 至 1.6 GHz 范围内。由于存在计算密集型线程，温度因持续接近热极限而稳定维持，TMP 不断尝试降低时钟频率。然而，由于交互式线程的处理器利用率也很高，QoS看门狗将时钟频率维持在1.3 GHz以上，这对于给定的工作负载而言是一个理想的水平。

V. 相关工作

热设计功耗（TDP）约束将成为设计新一代处理器时最重要的性能限制因素之一，因为在频率不变的情况下，每代核心数量翻倍将很快超过热设计功耗（TDP）[7]。这意味着必须探索应对热设计功耗（TDP）约束的创新方法[3]。Brooks等人[8]定义并研究了DTM方案的主要组成部分。具体而言，他们探讨了应对热创伤时期的多种机制之间的权衡，并研究了硬件和软件实现的影响。

Skadron等人[2]也构建了一个微架构热模型，并利用该模型比较了多种不同的动态热管理（DTM）技术，例如动态电压频率调节（DVFS）、将计算迁移到备用硬件单元，以及取指门控与DVFS的组合。TMP的冷却策略决策启发式方法可以通过采用考虑各自特性的多样化热管理机制来进一步优化。

Liu等人[9]提出了一种设计时模型，该模型分析工作负载并为实时约束创建任务到电压映射。这些映射具有多个目标：能量优化、热优化以及热约束能量优化。调度通过将最佳可能的映射分配给处理器来执行，同时不违反其当前的热和功率约束。Akbari等人[10]也提出了一种用于热管理的动态任务优先级缩放方法，该方法根据任务的优先级在多核处理器上进行映射和调度，以降低系统温度。

这些方法的目标是减少给定工作负载下的总散热，与 TMP的方法正交。因此，它们可以与TMP结合使用，在热危机情况下获得QoS保护方面的协同效益。

多媒体应用的服务质量（QoS）保护一直是电源管理方案中的一个重要问题，因为盲目地进行性能管理可能会严重损害用户体验。Kamat [11]提出了一种框架，使多媒体应用与能源管理模块相互协作，以延长多媒体应用的电池寿命。该框架预测电池充电模式，并利用这些信息进行电源管理。然而，其目标并非保持这些应用的QoS，相反，它是基于预测通过牺牲QoS来最大化电池寿命。

Hwang等人[12]设计了一种硬件支持的电源管理单元（PMU）。该硬件辅助PMU能够高效地收集应用程序的I/O使用模式信息。基于所收集的信息，PMU执行预测性电源管理。尽管所提出的方法能够主动响应工作负载特征，但这些信息仅用于提高能效，而非用于热管理。

斯里尼瓦桑等人[13]提出了一种预测性DTM方案，该方案旨在支持多媒体应用。所提出的预测模型基于一种算法，该算法通过分析应用程序适当数量的帧，以检查芯片所有结构中的最高温度。然后应用微架构适应来降低给定工作负载下的温度。该方法假设每个芯片配备一定数量的温度传感器，而这些传感器在嵌入式处理器中尚未可用。

唐纳德等人[14]探索了面向多核处理器的动态热管理（DTM）的新颖技术，并通过仿真对这些技术进行了评估。然而，目标工作负载主要是计算密集型和吞吐量导向的。

易等人 [3]提出了一种改进的热建模技术，可在设计阶段更准确、高效地预测芯片温度。此外，他们基于所提出的热模型开发了一种启发式算法，以解决静态应用映射和调度问题，从而控制工作温度。

楚等人 [15]为多核处理器开发了一种自适应在线热感知任务调度器。与TMP相同，它通过监控某些系统参数来寻找一个热效率高的核心以映射任务。不同于TMP的是，他们假设每个任务都会明确声明其服务级别要求。

费舍尔等人 [16]研究了如何调整多核SoC的执行速度以满足实时任务的热约束。在热模型方面，他们采用了傅里叶冷却模型，该模型以某种形式被大多数相关文献所采用。