Kubernetes如何影响程序的CPU缓存（如L3）局部性？

1. 调度驱逐对缓存效率的影响 #

会明确损失缓存效率，这是时间片共享调度的固有 trade-off。每次 Pod 对应的进程被抢占驱逐出 CPU 流水线时，该进程之前在 L1/L2/L3 缓存中加载的专用数据、指令块都会随着后续其他进程的调度逐渐被淘汰，下一次该 Pod 再被调度执行时，大概率需要重新从内存加载数据，直接表现就是 CPI（每指令周期数）升高、运行时延波动。

但 CPU 不会完全丢失所有缓存局部性，分为两种情况：

• 如果 Pod 下一次调度还是分配到同一个物理 CPU 核心，且驱逐时间短、期间调度的其他进程内存占用小，那么原有部分热点缓存块还会留存，通常能保留30%~60%左右的局部性收益，具体比例取决于负载的热点数据占比
• 如果被调度到其他核心，那么目标核心的私有缓存（L1/L2）里的内容完全不共享，只有 CPU 全局共享的 L3 缓存可能还留存部分公共数据，局部性收益会降到10%以下。

2. 容器保留缓存局部性的可行性 #

不存在安全层面的硬性限制，当前主流 CPU 和容器 runtime 都支持相关能力：

• 容器本质是宿主机上做了资源隔离的普通进程，和原生进程一样共享 CPU 缓存体系，没有额外的默认缓存擦除机制。只有主动开启了 CPU 侧信道攻击防护的缓存冲刷选项（比如内核启动参数 mitigations=auto 包含的部分安全规则），调度切换时才会主动冲刷 L1 缓存，这种场景下才会完全丢失私有缓存的局部性
• 如果要稳定保留缓存局部性，可以通过 K8s 的 CPU 管理器静态策略，给 Guaranteed 级别的 Pod 绑定固定的物理 CPU 核心，避免跨核心调度，就能最大化保留缓存局部性。

3. 同基础镜像共享.so文件的缓存留存问题 #

该场景下大概率可以持续留存于 L3 缓存中，底层逻辑如下：

• 多个容器调用同一份基础镜像里的 .so 文件时，宿主机 OverlayFS 会把该 .so 文件映射到同一份内核页缓存，对应的物理内存页是多容器共享的
• CPU 的 L3 缓存是所有物理核心全局共享的，只要这份共享页被频繁访问，不管是哪个容器的进程调用，调度切换时都不会主动淘汰这部分热点缓存，会一直留存在 L3 中，不需要反复从内存加载
• 只有当系统整体内存压力极大、页缓存被主动回收，或者很长时间没有任何进程访问该 .so 的时候，对应的缓存块才会被淘汰。

内容的提问来源于stack exchange，提问作者Bots Fab