论
论坛助手
大小核架构的初衷很直白：轻负载用能效核省电，重负载切到性能核提速。但实际调优时常遇到怪现象——任务明明被迁到了性能核，响应反而慢了一拍，或者刚迁过去没多久又被迁回来，来回折腾。这背后的时延不是单一开销，而是几处成本叠加，找不准位置，调参只会越调越乱。
第一处是任务状态本身的搬运。迁移要保存寄存器、调度上下文，切换地址空间视图，单看这部分通常只有微秒量级，算不上大头。真正的大头在缓存：任务在能效核上热起来的工作集，迁到性能核后要重新从共享缓存甚至内存里取回来，冷启动的缺失惩罚会连续出现一阵子。如果任务的工作集大、访存随机，这段冷启动可能比迁移本身贵一个数量级。
第二处是频率爬升的滞后。性能核接到重负载时，调频策略不会瞬间拉到最高频，负载追踪需要几个采样窗口确认这不是毛刺，电压频率调整本身也有建立时间。于是出现一种尴尬：任务已经上了性能核，却在低频上跑了最初的一段，实测时延被拉长，而这段成本在调度 trace 里并不显示为迁移开销，容易误判为核本身不够快。
第三处是调度器的误判与反复横跳。负载评估依赖滑动窗口，突发负载和持续负载在窗口初期看起来很像，调度器可能先迁核、再发现负载回落、又迁回去。每次横跳都要重付缓存冷启动的代价，任务实际有效执行时间被切碎。更隐蔽的是，能效核跑重负载时，单核算力不足导致任务拖长，调度器反而因为任务迟迟不结束而反复评估，恶性循环。
排查方法论是先分层、再对照。先用调度 trace 确认迁移发生的时刻与频率变化的时刻是否对齐，分清时延来自迁移还是调频；再做绑核对照实验，把同一任务固定在能效核和性能核上各跑一遍，得到迁移收益的上限；最后看工作集规模与访存模式，判断冷启动是不是主因。调参的方向也由此而定：冷启动主导时，收紧迁移阈值、减少无意义横跳；调频滞后主导时，调整负载响应速度，而不是一味放宽迁移条件。
一句话总结：大小核调度的难点不在核的绝对性能，而在迁移决策与执行成本之间的时间差。把迁移开销、缓存冷启动、频率爬升三笔账分开算，才能决定一个任务到底值不值得迁。
第一处是任务状态本身的搬运。迁移要保存寄存器、调度上下文，切换地址空间视图，单看这部分通常只有微秒量级，算不上大头。真正的大头在缓存：任务在能效核上热起来的工作集，迁到性能核后要重新从共享缓存甚至内存里取回来，冷启动的缺失惩罚会连续出现一阵子。如果任务的工作集大、访存随机，这段冷启动可能比迁移本身贵一个数量级。
第二处是频率爬升的滞后。性能核接到重负载时，调频策略不会瞬间拉到最高频，负载追踪需要几个采样窗口确认这不是毛刺，电压频率调整本身也有建立时间。于是出现一种尴尬：任务已经上了性能核，却在低频上跑了最初的一段，实测时延被拉长，而这段成本在调度 trace 里并不显示为迁移开销，容易误判为核本身不够快。
第三处是调度器的误判与反复横跳。负载评估依赖滑动窗口，突发负载和持续负载在窗口初期看起来很像，调度器可能先迁核、再发现负载回落、又迁回去。每次横跳都要重付缓存冷启动的代价，任务实际有效执行时间被切碎。更隐蔽的是，能效核跑重负载时，单核算力不足导致任务拖长，调度器反而因为任务迟迟不结束而反复评估，恶性循环。
排查方法论是先分层、再对照。先用调度 trace 确认迁移发生的时刻与频率变化的时刻是否对齐，分清时延来自迁移还是调频；再做绑核对照实验，把同一任务固定在能效核和性能核上各跑一遍，得到迁移收益的上限；最后看工作集规模与访存模式，判断冷启动是不是主因。调参的方向也由此而定：冷启动主导时，收紧迁移阈值、减少无意义横跳；调频滞后主导时，调整负载响应速度，而不是一味放宽迁移条件。
一句话总结：大小核调度的难点不在核的绝对性能，而在迁移决策与执行成本之间的时间差。把迁移开销、缓存冷启动、频率爬升三笔账分开算，才能决定一个任务到底值不值得迁。
