per-CPU variables 与本地数据

这页讲的是:有些状态并不适合让所有 CPU 共用同一份,因为一共用就会带来争用、缓存抖动和同步成本。学这页的重点,是理解 per-CPU data 的核心不是“复制很多份很浪费”,而是“把天然局部的状态留在本 CPU,换来更低争用和更清楚的执行关系”。

这块是什么

per-CPU variables 与本地数据,讲的是 Linux 怎样把某些统计、缓存、中间状态或短期工作上下文按 CPU 分开存放,让每个 CPU 更常访问自己的那一份,而不是频繁争抢全局共享对象。它关注的是“哪些状态天然适合本地化”,而不是简单把所有数据都复制一遍。

可以把它理解成:一家公司不是所有人都去抢同一个便签本,而是每个工位先有自己的便签区。只在必须汇总的时候,才把各工位的信息正式合起来看。

它负责什么

减少全局共享争用

  • 如果每次都改同一个全局计数或状态,多核下很容易打架
  • 把状态拆到每个 CPU,本地更新通常更便宜
  • 减少锁竞争和缓存来回抖动
  • 让高频路径更容易扩展到多核

保留 CPU 本地语义

  • 有些状态只对当前 CPU 当下执行最有意义
  • 本地缓存、本地统计、本地临时上下文都常属于这类
  • 让“谁在用、谁在更新”关系更清楚
  • 避免过早把局部问题做成全局问题

给后续汇总留出边界

  • 本地化不是永远不汇总
  • 很多时候只是把高频更新和低频汇总拆开
  • 让系统把最贵的同步推迟到真正需要时
  • 把“实时共享”变成“按需合并”

为什么它不是“偷懒不做同步”

如果想得太简单会怎样真正关键在哪
觉得这是为了逃避锁会低估它其实是在利用很多状态本来就具有 CPU 局部性。这不是绕开正确性,而是把共享范围设计得更合理。
把每 CPU 数据当完全独立真相会漏掉很多场景最后仍要汇总或跨 CPU 协作。本地化和全局视角经常要配合出现。
只看内存多占了几份会忽略省下的锁竞争和缓存一致性代价往往更关键。多核系统里同步成本常比那点复制更贵。
觉得当前任务永远留在本 CPU会忽略抢占和迁移会改变“当前到底在哪颗核上跑”。访问本地数据时经常要一起考虑执行连续性。

关键概念

概念现在怎么理解
per-CPU variable按 CPU 各自保存一份的变量或状态,让本地访问更便宜。
本地更新多数高频修改先只改当前 CPU 的那份,而不是立刻动全局对象。
汇总需要全局视图时,再把多个 CPU 的本地结果合并起来看。
CPU 局部性数据更常被哪颗 CPU 访问、更新,会直接影响设计是否适合本地化。
迁移 / 抢占约束如果执行可能中途换到别的 CPU,本地数据访问就得更认真保护上下文假设。

为什么重要

常见误解

它不负责什么

和其他模块的关系

相关模块关系
preemption 与抢占访问本地数据时,经常要确保自己不会中途被换到另一颗 CPU 继续跑。
调度器与 CPU 迁移任务可能被迁走,所以“当前 CPU 的本地状态”不是永远自然成立的。
锁与并发控制很多用 per-CPU 的目的就是缩小共享范围,减少全局锁需求。
NUMA 与局部性它们都在强调“资源离谁近、谁更常访问”会改变系统表现,只是粒度不同。

读完这页后,你应该能回答

后面适合继续问:关抢占和拿本地锁分别在保护什么?哪些统计值适合做成 per-CPU,哪些不适合?per-CPU 和 NUMA 局部性最容易被混在哪?