大小核架构的本意是让轻负载任务跑在能效高的小核上，重负载任务迁移到性能强的大核上，从而在性能和功耗之间取得平衡。这个迁移决策通常由调度器根据任务负载、运行队列长度和能效模型来做，而负载阈值就是触发迁移的那条线。阈值设得合理，任务能在合适的核上稳定运行；阈值设错，最典型的症状就是任务在大小核之间来回跳动，性能没上去，功耗反而增加了。

来回跳动的代价比直觉上更大。每一次迁移都要保存和恢复上下文，缓存亲和性会被打断，任务迁移到新核后往往要重新预热缓存，短期内执行效率反而下降。如果迁移发生在锁竞争或实时性敏感的临界区附近，还可能放大延迟抖动。更隐蔽的是功耗代价：大核被频繁唤醒又迅速闲置，电压频率调节来不及跟上，系统会在高功耗状态和低功耗状态之间反复切换，整体能效比一直待在小核上更差。

阈值设错通常有几种典型形态。第一种是上下阈值贴得太近，负载在阈值附近轻微波动就触发一次迁移，缺乏回滞区间。第二种是只看瞬时负载，没有做滑动平均或滤波，突发毛刺直接触发迁移，而毛刺过去后又立刻迁回。第三种是阈值没有区分任务类型，交互式任务和后台批处理任务共用同一套参数，前者需要快速响应，后者更看重吞吐，统一阈值必然顾此失彼。第四种是忽略了频率的影响，负载本身是归一化后的概念，大核和小核在不同频率下的算力不同，直接比较原始利用率会失真。

排查这类问题时，先不要急着改参数，要先拿到迁移轨迹。记录任务在一段时间内的迁移次数、每次停留时长、迁移前后的负载和频率，就能判断是阈值问题还是负载估计问题。如果停留时间普遍很短且迁移频繁，优先检查回滞区间和滤波窗口；如果迁移集中在特定任务上，检查该任务的负载特性是否被误判；如果问题只在某些场景出现，比如亮屏或后台同步期间，要看是否有其他调度策略在同时干预。

调优的原则是先稳定、再优化。给上下迁移设置足够宽的回滞带，对负载做适当平滑，迁入大核的门限可以略高于迁回小核的门限，让任务在大核上多待一会儿，把迁移成本摊薄。对延迟敏感任务可以适当放宽迁入条件，对后台任务则可以收紧，避免它们无谓地占用大核。每次只改一个参数并做前后对照，记录功耗和性能的变化，避免多个参数同时改动导致无法归因。大小核调度的目标不是让大核尽量多干活，而是让每个任务在合适的核上待得足够久。