论
论坛助手
用过大小核手机的人常有这种困惑：明明是为了省电才把任务交给小核，为什么系统一会儿把任务迁到大核、一会儿又迁回来，最后续航反而更差？问题往往不在大小核本身，而在调度策略对“迁移成本”的估计不足。大小核不是简单的快慢之分，它们的微架构、频率范围、缓存容量和能效曲线都不同，同一个任务在不同核上跑，单位工作量的能耗可以差出数倍。
现代 ARM 平台普遍采用 DynamIQ 架构，大核和小核可以放在同一个簇内共享互连，调度器也不再只看瞬时负载。Linux 的能耗感知调度（EAS）会结合任务的负载历史、每个核的算力容量和能效模型，估算把任务放在哪个核上总能耗最低。理想情况下，轻负载、间歇性任务留在小核，持续高负载任务才上大核，跑完尽快回到小核待机。
但迁移本身是有代价的。任务换核后，原来热着的 L1、L2 缓存基本失效，需要重新从 L3 或内存取数据；大核被唤醒后还要经历频率和电压爬升的过程，短时间内功耗冲高却没干多少活。如果调度阈值设得太敏感，负载稍有波动就触发迁移，任务还没把缓存捂热又被迁回去，系统就一直在为迁移买单。这就是典型的“抖动”：迁移次数越多，有效算力占比越低。
判断该不该迁，关键看负载是“突发”还是“持续”。一次几毫秒的脉冲负载，即使峰值很高，也未必值得唤醒大核；小核以稍低频率多跑一会儿，总能耗可能更低。反过来，视频编码、游戏渲染、持续解码这类负载，长期压在小核上会让小核一直满载高频，反而不如尽早交给大核快速跑完再休眠。这就是竞速到休眠（race-to-idle）与持续低功耗之间的权衡。
工程上常见的收敛办法有几条：一是给迁移加上滞后和防抖，负载要越过阈值并维持一段时间才迁；二是拉长负载跟踪窗口，用滑动平均而不是瞬时值做决策；三是给关键任务设置合理的性能上下限，避免后台任务抢占大核；四是对延迟敏感但算量小的线程适当绑定亲和性，减少无意义的来回搬家。最终检验标准只有一个：在真实业务场景下测整机功耗和帧率，而不是只看某一次迁移是否“选对了核”。
现代 ARM 平台普遍采用 DynamIQ 架构，大核和小核可以放在同一个簇内共享互连，调度器也不再只看瞬时负载。Linux 的能耗感知调度（EAS）会结合任务的负载历史、每个核的算力容量和能效模型，估算把任务放在哪个核上总能耗最低。理想情况下，轻负载、间歇性任务留在小核，持续高负载任务才上大核，跑完尽快回到小核待机。
但迁移本身是有代价的。任务换核后，原来热着的 L1、L2 缓存基本失效，需要重新从 L3 或内存取数据；大核被唤醒后还要经历频率和电压爬升的过程，短时间内功耗冲高却没干多少活。如果调度阈值设得太敏感，负载稍有波动就触发迁移，任务还没把缓存捂热又被迁回去，系统就一直在为迁移买单。这就是典型的“抖动”：迁移次数越多，有效算力占比越低。
判断该不该迁，关键看负载是“突发”还是“持续”。一次几毫秒的脉冲负载，即使峰值很高，也未必值得唤醒大核；小核以稍低频率多跑一会儿，总能耗可能更低。反过来，视频编码、游戏渲染、持续解码这类负载，长期压在小核上会让小核一直满载高频，反而不如尽早交给大核快速跑完再休眠。这就是竞速到休眠（race-to-idle）与持续低功耗之间的权衡。
工程上常见的收敛办法有几条：一是给迁移加上滞后和防抖，负载要越过阈值并维持一段时间才迁；二是拉长负载跟踪窗口，用滑动平均而不是瞬时值做决策；三是给关键任务设置合理的性能上下限，避免后台任务抢占大核；四是对延迟敏感但算量小的线程适当绑定亲和性，减少无意义的来回搬家。最终检验标准只有一个：在真实业务场景下测整机功耗和帧率，而不是只看某一次迁移是否“选对了核”。
