1. 从一次设备烫手的排查说起thermal framework 到底在管什么很多人第一次接触 Linux 功耗子系统都是从板子跑着跑着就烫得不敢摸开始的。我也一样。早些年调一块嵌入式板子跑压力测试不到十分钟外壳温度直接飙到烫手系统日志里却干干净净什么报错都没有。当时我的第一反应是散热设计有问题换了散热片、加了风扇温度是压下去了但功耗和性能的账一直没算明白——风扇全速转续航崩了噪音也上来了。后来才意识到问题根本不在散热硬件而在于我压根没让内核的thermal framework参与进来温度失控时没有任何降频、限流的动作全靠硬件硬扛。这就是 thermal framework 存在的意义它是 Linux 内核功耗子系统里专门负责温度感知与热管理的一层通用架构。简单说它干三件事——感知温度从各种温度传感器读数据、判断策略温度到了什么阈值该做什么、执行动作降频、限流、关核、调风扇。它把温度源和降温手段解耦成两套抽象中间用一套策略逻辑串起来这样换一颗 SoC、换一种散热方案上层逻辑基本不用大改。这套框架适合谁看如果你是做嵌入式 Linux 开发的、搞功耗优化的、调过设备发烫问题的或者准备面试被问到内核功耗子系统那 thermal framework 是绕不开的一环。它不像调度器那么复杂但概念多、抽象层次绕第一次看源码容易晕。我这篇就按我自己梳理的思路把thermal zone、cooling device、governor、trip point这几个核心概念和它们之间的关系讲透再补上实操里真正会踩的坑。需要先说明一点thermal framework 的代码在不同内核版本之间有过比较大的重构尤其是 4.18 之后把原来的 thermal zone 注册方式、governor 接口都动过。我下面讲的是通用架构层面的东西具体函数名和结构体字段你对着自己手上的内核版本看大方向是一致的细节以源码为准。这也是我建议的阅读方式——先建立架构图再钻进具体版本。2. thermal framework 的整体架构与设计思路拆解2.1 为什么要把温度源和降温手段拆开理解 thermal framework最关键的一步是理解它为什么这么分层。你可以把它想象成一个公司的温度管理流程车间里装了若干温度计温度源仓库里有若干台空调和风扇降温手段中间坐着一个主管governor主管根据温度计读数决定开哪台空调、开多大。如果不用这套抽象直接在每个驱动里写温度超过 80 度就把 CPU 频率降到 1GHz会有什么问题第一温度源和降温手段强耦合换一个传感器就得改一遍逻辑第二多个温度源、多个降温手段交叉时逻辑会爆炸第三策略无法复用每块板子重写一遍。thermal framework 的设计初衷就是解决这三个问题它把系统拆成四个角色thermal zone一个热区代表一个需要被监控的温度区域比如 CPU 集群、GPU、电池、外壳。它绑定一个或多个温度传感器并定义一组触发点trip point。thermal sensor / thermal zone device真正读温度的设备比如 SoC 内部的 TSADC、外部的 I2C 温度芯片。cooling device可以降温的设备比如 CPUfreq调频、devfreq调 GPU/内存频率、风扇、甚至直接关核。governor策略大脑决定在某个温度下调用哪些 cooling device、用多大力度。这四者通过内核里的设备模型和通知机制连起来。thermal zone 注册时会去绑定 sensor 和 cooling devicegovernor 则在温度变化时被回调做出决策。整个链路是传感器上报 → thermal core 更新温度 → governor 决策 → 调用 cooling device 的降温接口。2.2 核心数据结构之间的关系从代码层面看几个关键结构体撑起了整个框架。struct thermal_zone_device是热区的核心里面挂着温度读取回调、trip 数组、绑定的 cooling device 列表、当前 governor 指针。struct thermal_cooling_device代表一个降温设备核心是struct thermal_cooling_device_ops里面最关键的是get_max_state和set_cur_state两个回调——前者告诉框架这个设备最多有几档后者用来设置当前档位。struct thermal_governor是策略接口核心是throttle回调温度变化时被调用。trip point 用struct thermal_trip描述包含温度值、类型passive、active、critical、hot和绑定的 cooling device 及触发参数。它们的关系可以这样理解thermal zone 是舞台trip point 是剧本里的触发条件cooling device 是演员governor 是导演。导演看着舞台上的温度按剧本决定让哪个演员上、演到什么程度。2.3 与内核其他子系统的耦合点thermal framework 不是孤立的它和好几个子系统有交互。最直接的是CPUfreq——CPU 降频是最常用的降温手段thermal 通过 cooling device 接口调用 cpufreq 的限频能力。其次是devfreq用于 GPU、DDR 等设备的频率调节。还有regulator某些场景下通过降压来降功耗。风扇控制则通常走hwmon或PWM子系统。另外thermal 还通过sysfs暴露大量节点给用户态比如/sys/class/thermal/thermal_zone0/temp读温度、/sys/class/thermal/cooling_device0/cur_state看当前档位。用户态也可以写这些节点做手动干预调试时非常有用。还有netlink接口用于向用户态上报 thermal 事件Android 的 thermal 服务就靠这个。理解这些耦合点很重要因为实际排查问题时温度没降下来可能是 thermal 没触发也可能是触发了但 cpufreq 没响应链路任何一环断了都会表现为温度失控。3. thermal zone 与 trip point温度感知的核心细节3.1 thermal zone 是怎么注册和绑定传感器的一个 thermal zone 的诞生通常来自设备树Device Tree里的描述。以常见的 SoC 为例DTS 里会有类似这样的节点thermal-zones { cpu_thermal: cpu-thermal { polling-delay-passive 100; polling-delay 1000; thermal-sensors tsadc 0; trips { cpu_alert: cpu-alert { temperature 70000; hysteresis 2000; type passive; }; cpu_crit: cpu-crit { temperature 95000; hysteresis 2000; type critical; }; }; cooling-maps { map0 { trip cpu_alert; cooling-device cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT; }; }; }; };这段描述里信息量很大。polling-delay是轮询间隔单位毫秒1000 表示每秒读一次温度polling-delay-passive是进入被动降温后的轮询间隔通常会调小因为这时候需要更灵敏地响应。thermal-sensors指向具体的传感器。trips定义触发点cooling-maps把触发点和降温设备绑起来。内核启动时thermal core 解析这些节点创建thermal_zone_device调用 sensor 驱动的注册接口把温度读取回调挂上。这里有个细节polling-delay 设得太大温度响应会迟钝设得太小频繁读传感器又增加功耗。我一般被动降温阶段设 100ms 左右正常监控设 1000ms具体看传感器读取开销。3.2 trip point 的四种类型与触发逻辑trip point 是 thermal 的剧本它定义了在什么温度下做什么。类型主要有四种理解它们的区别是调 thermal 的基本功类型含义典型动作是否可恢复passive被动降温降频、限流可恢复active主动降温开风扇可恢复hot高温预警通知用户态可恢复critical临界温度关机/重启不可恢复passive 和 active 的区别在于降温手段passive 靠减少发热降频active 靠增加散热风扇。hot 一般只做事件上报不直接执行动作。critical 是最后一道防线温度到了这里系统会直接触发关机防止硬件损坏。每个 trip 还可以配hysteresis迟滞这个参数非常关键。假设触发温度是 70 度迟滞 2 度那么温度升到 70 度触发降温但要降到 68 度以下才会解除降温。没有迟滞的话温度在 70 度附近抖动会导致降温动作反复开关系统震荡。我踩过这个坑早期没配迟滞风扇在阈值附近疯狂启停噪音像机关枪。3.3 温度读取的两种模式轮询与中断thermal zone 读温度有两种模式。默认是轮询按polling-delay周期性地调用 sensor 的读取回调。另一种是中断/事件驱动传感器温度越限时主动上报thermal core 收到后再更新。后者更省电但需要硬件支持。轮询模式下有个容易忽略的点如果 sensor 读取失败thermal core 会怎么处理。早期版本里读取失败可能直接返回错误导致温度值不更新governor 拿不到新数据。较新的内核会做重试和错误计数。实际调试时如果发现温度值一直不变先确认 sensor 驱动是否正常返回别急着怀疑 governor。另外polling-delay和polling-delay-passive的切换时机也值得注意。系统正常时用大间隔省电一旦某个 passive trip 被触发就切到小间隔提高响应速度。这个切换是 thermal core 自动做的但前提是你的 DTS 里两个参数都配了。4. cooling device 与 governor降温执行与策略决策4.1 cooling device 的注册与档位抽象cooling device 的核心抽象是档位state。每个降温设备从 0 到 max_state 分成若干档0 通常表示不降温max_state 表示最大降温力度。框架不关心这一档具体是什么只关心调高一点和调低一点。以 CPUfreq 为例它的 cooling device 实现里get_max_state返回的是可用频率档位的数量set_cur_state则把频率限制到对应档位。比如一个有 8 个频率档的 CPUmax_state 是 7设置 state3 就限制到第 3 档频率。风扇的 cooling device 则把档位映射到 PWM 占空比或转速等级。注册 cooling device 的典型流程是驱动里调用thermal_cooling_device_register传入名字、私有数据和 ops。名字很重要因为 cooling-maps 里通过 phandle 绑定实际匹配靠的是设备节点。这里有个常见错误cooling device 注册晚于 thermal zone导致 zone 初始化时找不到设备绑定失败。解决办法是保证驱动 probe 顺序或者用 deferred probe 机制。4.2 governor 的几种策略与选择依据governor 是策略大脑内核里常见的有这几种step_wise最常用。温度超过 trip 时逐步增加降温档位温度回落时逐步减少。它的特点是温和不会一步到位避免过度降温影响性能。power_allocator基于功耗预算的精细控制适合需要精确功耗管理的场景配置复杂但效果好。fair_share多个 cooling device 之间按权重分配降温力度。bang_bang最简单的开关式超过阈值就最大力度降温低于阈值就停。响应快但容易震荡。user_space把决策权交给用户态内核只上报事件。选哪个 governor取决于你的场景。手机、平板这类对续航和体验都敏感的常用 step_wise 或 power_allocator工业设备只要不烧就行bang_bang 也够用需要用户态精细控制的用 user_space。我个人的经验是先用 step_wise 跑通确认链路没问题再考虑换 power_allocator 做精细优化。一上来就上 power_allocator参数没调好反而容易出现降温不足或过度降温。4.3 从温度到动作一次完整的降温链路把前面几块拼起来一次完整的降温是这样发生的轮询周期到了thermal core 调用 sensor 读取回调拿到当前温度。温度值和所有 trip point 比较判断是否有 trip 被跨越。如果有 trip 被触发通知当前 governor。governor 根据策略决定调用哪些绑定的 cooling device设置什么档位。cooling device 的set_cur_state被调用实际执行降频、开风扇等动作。温度回落后governor 逐步降低降温力度直到解除。这条链路里任何一环出问题都会导致降温失效。我排查时习惯从两头夹先看/sys/class/thermal/thermal_zone0/temp温度是否正常更新再看/sys/class/thermal/cooling_device0/cur_state档位是否变化。两头都正常问题就在中间的 governor 或 trip 配置一头不动就顺着那一头查。5. 实操从零配置一个 thermal zone 并验证5.1 确认硬件与内核支持动手之前先确认三件事内核是否编了 thermal 相关配置、传感器驱动是否加载、设备树是否有对应节点。检查内核配置zcat /proc/config.gz | grep -i thermal或者直接看/boot/config-$(uname -r)。需要确认的选项包括CONFIG_THERMAL、CONFIG_THERMAL_GOV_STEP_WISE、CONFIG_CPU_THERMAL、CONFIG_THERMAL_OF等。如果这些没开后面全是白搭。然后看系统里有没有 thermal zonels /sys/class/thermal/正常应该能看到thermal_zone0、cooling_device0之类的目录。如果只有 cooling_device 没有 thermal_zone说明 zone 没注册成功回去查 DTS 和 sensor 驱动。5.2 读取温度与查看 trip 配置读当前温度cat /sys/class/thermal/thermal_zone0/temp返回值单位是毫摄氏度比如 45000 表示 45 度。查看这个 zone 的类型和 trip 点cat /sys/class/thermal/thermal_zone0/type cat /sys/class/thermal/thermal_zone0/trip_point_0_temp cat /sys/class/thermal/thermal_zone0/trip_point_0_typetrip 点的编号从 0 开始依次对应 DTS 里定义的顺序。如果 trip_point 节点不存在说明 DTS 里 trips 没配或者解析失败。5.3 手动触发降温验证链路最直接的验证方法是手动设置 cooling device 档位看频率是否真的降下来。先看 cooling device 的档位范围cat /sys/class/thermal/cooling_device0/max_state cat /sys/class/thermal/cooling_device0/cur_state然后手动设一个较高的档位echo 3 /sys/class/thermal/cooling_device0/cur_state同时用cpufreq-info或直接读/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq看频率是否被限制。如果档位设了但频率没变说明 cooling device 的set_cur_state实现有问题或者 cpufreq 的限频接口没接上。注意手动写 cur_state 会覆盖 governor 的决策验证完记得把它设回 0或者重启 thermal 服务否则 governor 可能不再接管。5.4 用 stress 工具做真实升温测试手动验证链路通了之后用真实负载测试。装个stress或stress-ng跑满 CPUstress-ng --cpu 4 --timeout 300s同时开一个窗口盯着温度和档位watch -n 1 cat /sys/class/thermal/thermal_zone0/temp; cat /sys/class/thermal/cooling_device0/cur_state正常情况下温度会逐渐上升到 passive trip 后档位开始增加频率被限制温度趋于稳定。如果温度一路飙升到 critical 触发关机说明降温力度不够或者 trip 配置不合理。5.5 参数调整的经验值调 thermal 参数没有万能公式但有一些经验区间。polling-delay 正常监控 1000ms 左右被动降温 100~200ms。passive trip 温度一般设在 SoC 结温上限往下留 15~20 度比如结温上限 105 度passive 设 85 度左右。critical 设在结温上限往下留 5 度比如 100 度。hysteresis 一般 2000~5000 毫摄氏度太小容易震荡太大响应迟钝。这些值都要结合具体硬件的散热能力和使用场景调。同样的 SoC放在金属外壳和塑料外壳里散热能力差很多trip 温度不能照搬。6. 常见问题与排查技巧实录6.1 温度不更新或读数异常最常见的现象是temp节点读出来一直是同一个值或者明显不合理比如 -273 度。排查顺序先确认 sensor 驱动是否 probe 成功dmesg | grep -i thermal看有没有报错再确认 DTS 里 sensor 节点和 thermal zone 的引用是否正确最后看 sensor 的读取回调是否真的被调用可以加 printk 或 ftrace 跟踪。有个隐蔽的坑某些 sensor 需要先配置寄存器、启动转换才能读到有效值。如果驱动里漏了初始化步骤读出来就是默认值或 0。这种情况在自研板子上很常见。6.2 降温动作不生效温度到了 trip 但频率没降、风扇没转问题可能在三个地方trip 和 cooling device 的绑定关系没建立、governor 没被正确设置、cooling device 的 set_cur_state 实现有问题。检查绑定关系看/sys/class/thermal/thermal_zone0/cdev0/目录是否存在检查 governor 看cat /sys/class/thermal/thermal_zone0/policy。我遇到过一次cooling-maps 里 cooling-device 的 phandle 写错了指向了一个不存在的节点内核解析时静默失败日志里只有一行不起眼的 warning。所以 DTS 改完一定要看完整启动日志别只看有没有 panic。6.3 温度在阈值附近震荡这是迟滞没配好或者 governor 策略太激进导致的。step_wise 本身比较温和但如果 hysteresis 是 0温度在 trip 附近抖动就会导致档位反复切换。解决办法是给每个 trip 加合理的 hysteresis一般 2000 起步。如果还是震荡考虑换更平滑的 governor或者调整 step_wise 的步进逻辑。6.4 critical 触发关机但没日志critical trip 触发时系统会直接调用关机流程有时候日志来不及落盘。想排查这种情况可以先把 critical 温度调高或者临时把 critical trip 的类型改成 hot只上报不关机观察温度走势。另外内核的 pstore/ramoops 机制可以在重启后保留上次的日志配置好之后对排查这类问题很有帮助。6.5 多 thermal zone 之间的干扰复杂 SoC 上往往有多个 thermal zone比如 CPU、GPU、DDR 各一个但它们可能共享同一个 cooling device比如都调 CPU 频率。这时候多个 governor 同时操作一个 cooling device会互相覆盖。内核较新版本引入了 thermal zone 之间的绑定和优先级机制来缓解但配置复杂。实际项目里我倾向于让不同 zone 绑定不同的 cooling device减少交叉。下面这张表是我整理的高频问题速查现象可能原因排查入口温度不更新sensor 驱动未 probe / DTS 引用错dmesg、/sys/class/thermal降温不生效绑定失败 / governor 未设cdev 目录、policy 节点阈值附近震荡hysteresis 为 0trip_point_x_hystcritical 无日志关机太快pstore、临时改 trip 类型多 zone 互相干扰共享 cooling device检查 cooling-maps 绑定6.6 调试 thermal 的实用技巧分享几个我常用的技巧。第一善用thermal_zone的mode节点可以临时把 zone 切到 disabled 或 user_space 模式方便隔离问题。第二用 ftrace 跟踪thermal_zone_device_update和 governor 的 throttle 回调能清楚看到每次温度更新触发了什么。第三调试阶段把 polling-delay 调小让响应更快方便观察上线前再调回去。第四别忘了看/sys/class/thermal/thermal_zone0/下所有节点很多信息藏在那里比如available_policies会列出当前 zone 支持的 governor。7. 我对 thermal framework 的一点使用体会梳理完这套架构我最大的感受是thermal framework 的难点不在单个模块而在链路和配置。它的抽象设计其实很清晰温度源、降温手段、策略三者解耦思路和很多内核子系统一脉相承。真正让人头疼的是设备树里那一堆引用关系、trip 和 cooling device 的绑定、以及不同内核版本之间的接口变化。我现在的习惯是拿到一块新板子先把 thermal 相关的 DTS 节点和 sysfs 节点全部过一遍确认温度能读、档位能设、governor 能切再上负载测试。这套流程走下来大部分问题在早期就能暴露不至于等到设备烫手了才回头查。另外提醒一句thermal 参数没有一劳永逸的配置。同一块板子跑不同的业务负载、放在不同的环境温度下最优参数都不一样。上线前一定要在目标场景里实测别拿实验室的数据直接套。这个内容后续还可以往 power_allocator 的功耗预算模型、thermal zone 之间的协同、以及用户态 thermal 服务的方向继续展开那些是更精细的优化话题了。