缓存分区、QoS 与干扰建模
更新时间：2026-10-01。单核平均性能好做，难的是多核共享时性能不可预测；QoS 建模把“被邻居拖慢”变成可量化、可隔离的量。
本文要回答的问题
- 共享缓存下任务性能为什么会抖动？
- 分区怎么给出性能下界？
- 怎么量化“干扰”？
一、干扰来源
多个核共享 LLC 和内存带宽时，一个核的工作集会 evict 另一核的缓存行（互相污染），并争抢 DRAM 带宽/行缓冲。单独运行（solo）很快的任务，与噪声邻居共跑（co-run）可能显著变慢，且随邻居行为剧烈抖动。
二、缓存分区与带宽 QoS
- way-partitioning / Intel CAT：把某些 cache way 保留给指定核，保证最小容量不被抢。
- 页着色：用物理地址位把不同任务映射到不重叠 cache 切片。
- 内存带宽限速/优先级：限制一个请求源占用的带宽，保护关键流量。
三、干扰量化
用“减速比/灵敏度”衡量任务对干扰的脆弱性；分区虽可能略降平均利用率，但换来可预测的下界，对混合关键度（安全认证）和云 SLA 至关重要。
四、gem5 建模
gem5 支持缓存/内存 QoS 策略（优先级、限速、分区）；用不同攻击性的“干扰者”与受害任务组合，扫描分区配置，观察减速比与尾部分布，而非只看总吞吐。
五、常见坑
- 只测各核单独性能，集成后才发现抖动。
- 只盯总吞吐，忽视关键任务的性能下界。
- 分区过细，平均利用率和公平性受损。
- 只分缓存不分带宽，干扰仍从 DRAM 侧进入。
- 用平均延迟代替尾部分布做 QoS 判断。
小结
共享缓存/带宽产生 co-run 干扰，分区与限速用少量平均吞吐换可预测的性能下界，价值要按减速比和尾部衡量。下一篇 模型验证与统计置信度。
总结
多核共享 LLC 和内存带宽会让任务在 co-run 时被邻居 evict 和争抢而剧烈抖动，QoS 建模的核心是用 solo/co-run 减速比量化干扰脆弱性，并用 way 分区、页着色和带宽限速牺牲少量平均吞吐，换取混合关键度与云 SLA 需要的可预测性能下界。