大小核架构（big.LITTLE）：任务调度背后的权衡

手机 SoC 早就是大小核了，但很多人对它的理解还停留在"大核干活、小核省电"八个字。调度器在背后做的权衡，比这复杂得多。

一、为什么要有大小核

大核（性能核）：乱序发射、深流水线，单线程性能强，但功耗和面积都贵。小核（能效核）：顺序或轻度乱序，功耗低一个数量级，跑轻负载绰绰有余。手机的典型负载是碎片化的：刷信息流、后台同步、偶尔打游戏——全用大核，电池顶不住；全用小核，体验顶不住。

二、调度器的难题：任务往哪放

早期方案是簇迁移（cluster migration）：整个簇要么全开大核、要么全开小核，粒度太粗。现在主流是全局任务调度（GTS）加能效感知调度（EAS）：每个任务独立选核，依据是任务近期的负载（utilization）和每颗核的能效曲线。轻任务沉到小核，重任务浮到大核，动态平衡。

三、迁移不是免费的

任务换核要付出代价：私有 L1/L2 缓存的亲和性丢失，去了新核等于冷启动预热；迁移本身也有开销。所以调度器设了"迁移阈值"：负载变化没超过阈值就按兵不动，避免任务在大小核之间来回乒乓，白白烧电还掉性能。

四、给开发者的实战建议

第一，别硬绑定线程到核。除非是音频、DSP 这类实时性极强的线程，手动绑核通常跑输调度器——你把重任务绑在小核上，调度器想救都救不了。

第二，警惕"唤醒风暴"。频繁 wakeup 的后台任务会被反复调度，每次唤醒都可能把大核点亮。合并定时器、减少轮询，比纠结"放哪个核"省电得多。

第三，用 perf 看真相。做性能分析时，看任务实际跑在哪个核、迁移了几次，比凭感觉猜靠谱得多。

一句话：大小核是"能效优先、性能兜底"的硬件哲学，调度器负责在两者之间走钢丝。应用层最好的配合就是别添乱：少唤醒、不乱绑核。

大小核调度的难点在「任务不可预知」——调度器不知道下一个任务到底是长跑还是短跑。Linux 的 EAS（Energy Aware Scheduling）思路是用任务的 util 历史预测需求，再把任务放到「能效最优」的核上，而不是简单的「大核优先」。实际效果取决于负载特征：后台任务多、并发高的时候收益明显；单一重载任务跑到底的场景，大小核帮不上什么忙，甚至因为迁移开销略差。所以同架构下大核数量和调度策略的配比，要看目标场景的负载画像来定，没有普适最优。