关于Per-CPU变量性能提升逻辑的技术问询

你的疑惑核心在于：既然多CPU系统中任务调度和其他全局数据仍会引发缓存/TLB失效，那非高频使用的Per-CPU变量到底能带来哪些实际性能提升？其实Per-CPU变量的价值远不止“高频使用”这一个场景，以下是关键原因：

1. 消除锁竞争的隐性开销 #

普通全局变量在多CPU访问时必须依赖锁（如spin_lock(&global_lock)），锁的开销不仅包括原子操作本身，还可能带来CPU等待、调度延迟甚至优先级反转。哪怕变量的访问频率不算顶级高，只要涉及多CPU并发，锁的累积开销就会非常可观。

Per-CPU变量不需要跨CPU锁（除非主动跨CPU访问），每个CPU仅操作自己的副本，彻底规避了锁竞争的所有隐性开销。比如内核中的进程创建计数、中断统计，这类操作频率中等，但用Per-CPU实现后，省去了每次操作的锁等待，整体系统的并发效率会明显提升。

2. 持续的缓存局部性收益 #

任务被调度到其他CPU时，Per-CPU变量的缓存行属于目标CPU的独立副本，当任务后续被调度回原CPU时，之前的缓存行大概率仍处于有效状态（只要该CPU的缓存未被其他任务完全覆盖）。而普通全局变量的缓存行一旦被其他CPU修改，就会触发失效，再次访问时必须重新从内存加载。

此外，Per-CPU变量通常被内核放在连续的物理内存区域，内存布局规整，能大幅提升缓存命中率——这部分收益是持续的，哪怕变量的使用频率不高，也能减少不必要的内存访问开销。

3. 避免全局缓存震荡 #

有些变量虽然单CPU访问频率不高，但多CPU同时访问时会导致缓存行在多个CPU之间频繁“ping-pong”（即缓存行失效-加载的循环），这种全局缓存震荡会消耗大量CPU周期。

比如内核中的某些状态标记、临时统计值，用Per-CPU实现后，每个CPU维护自己的副本，彻底避免了多CPU之间的缓存行竞争。哪怕每个CPU仅偶尔访问，全局来看也能减少大量缓存失效事件，降低系统整体的内存总线压力。

4. TLB友好的内存布局优化 #

Linux内核为Per-CPU变量设计了特殊的虚拟地址映射：所有CPU的Per-CPU区域使用相同的虚拟地址，但映射到各自独立的物理地址。这种设计使得TLB条目可以在CPU之间共享，不需要为每个CPU的Per-CPU变量单独刷新TLB。

相比之下，普通全局动态变量的内存分配可能会频繁修改页表，触发TLB失效。Per-CPU的这种布局哪怕变量使用频率不高，也能间接减少TLB刷新的次数，提升系统的内存访问效率。

总结来说，Per-CPU变量的性能收益核心在于规避并发冲突、优化缓存与TLB行为，而非单纯依赖“高频使用”。哪怕数量不多，只要命中了容易引发锁竞争或缓存震荡的场景，就能为系统带来显著的性能提升。

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