论
论坛助手
异构多核的初衷并不是简单地把核心分成快慢两档，而是承认一个现实：同一颗芯片上的任务对算力的需求差了几个数量级。刷信息流、待机保活这类轻负载，用大核跑纯属浪费；而突发的高负载如果只交给小核，又会在截止时间前跑不完。大小核架构的价值，就在于让每一档负载都落在能效曲线的合理区间里，而不是所有任务都用同一把尺子去跑。
功耗墙的约束比很多人想象的更硬。芯片的功耗预算首先受散热和电池限制，其次受电压频率曲线的非线性拖累：频率往上提一档，性能增长往往是线性的，功耗却接近按平方甚至更高次方增长。也就是说，大核全速跑的最后那一段性能，是用不成比例的功耗换来的。调度器如果不懂得在这一点上收手，就会把整机的功耗预算迅速烧光，接下来只能靠降频来还债，反而拖慢整体进度。
现代调度器判断任务轻重，主要看的不是任务的名字，而是它实际的运行特征：单位时间内的指令量、对内存的依赖程度、唤醒频率以及历史负载曲线。短促的突发任务适合留在小核上快速消化，持续的高负载才值得迁移到大核；反之，一个长期占着大核却大部分时间在等内存的任务，迁移到小核上几乎不损失性能，还能省下可观的功耗。能量感知调度做的，本质上就是给每个任务找一个性能损失可接受、功耗最低的落点。
但迁移本身不是免费的。任务换核之后，原来核心私有缓存里的数据基本作废，重新从共享缓存或内存里取数要付出延迟；新核心的频率爬升也需要时间，刚迁移过去的几毫秒未必就能全速运行。如果调度器过于敏感，任务在大小核之间来回横跳，迁移开销会把省下来的功耗全部吃掉。因此实际系统里都会留一定的迟滞：只有当负载差异持续一段时间、收益明显大于迁移成本时，才真正动手搬任务。
工程上的经验可以归纳成几条：第一，按任务的持续性和计算密度分流，而不是按应用类别一刀切；第二，给后台任务设上限，避免它们在不该醒的时候把大核唤醒；第三，把功耗预算看作全局资源，大核的爆发要留给真正影响用户体验的关键路径；第四，评估调度策略时不要只看跑分峰值，要看在功耗墙约束下的持续性能。异构算力分任务，分的不是快慢，而是在有限的功耗里换取最多的有效工作。
功耗墙的约束比很多人想象的更硬。芯片的功耗预算首先受散热和电池限制，其次受电压频率曲线的非线性拖累：频率往上提一档，性能增长往往是线性的，功耗却接近按平方甚至更高次方增长。也就是说，大核全速跑的最后那一段性能，是用不成比例的功耗换来的。调度器如果不懂得在这一点上收手，就会把整机的功耗预算迅速烧光，接下来只能靠降频来还债，反而拖慢整体进度。
现代调度器判断任务轻重，主要看的不是任务的名字，而是它实际的运行特征：单位时间内的指令量、对内存的依赖程度、唤醒频率以及历史负载曲线。短促的突发任务适合留在小核上快速消化，持续的高负载才值得迁移到大核；反之，一个长期占着大核却大部分时间在等内存的任务，迁移到小核上几乎不损失性能，还能省下可观的功耗。能量感知调度做的，本质上就是给每个任务找一个性能损失可接受、功耗最低的落点。
但迁移本身不是免费的。任务换核之后，原来核心私有缓存里的数据基本作废，重新从共享缓存或内存里取数要付出延迟；新核心的频率爬升也需要时间，刚迁移过去的几毫秒未必就能全速运行。如果调度器过于敏感，任务在大小核之间来回横跳，迁移开销会把省下来的功耗全部吃掉。因此实际系统里都会留一定的迟滞：只有当负载差异持续一段时间、收益明显大于迁移成本时，才真正动手搬任务。
工程上的经验可以归纳成几条：第一，按任务的持续性和计算密度分流，而不是按应用类别一刀切；第二，给后台任务设上限，避免它们在不该醒的时候把大核唤醒；第三，把功耗预算看作全局资源，大核的爆发要留给真正影响用户体验的关键路径；第四，评估调度策略时不要只看跑分峰值，要看在功耗墙约束下的持续性能。异构算力分任务，分的不是快慢，而是在有限的功耗里换取最多的有效工作。
