PerCPU

perCPU refers to a design approach used in operating systems and performance‑critical software where data is allocated separately for each processor core. In a multi-core system, a perCPU data structure contains one instance per CPU, so there is a distinct copy for every active processor. Code operating on perCPU data typically uses the current CPU’s identity or an explicit CPU index to access that CPU’s private instance, reducing cross‑CPU contention.

The main motivation for perCPU data is to minimize locking and synchronization overhead on hot paths. By giving each CPU its own copy of frequently updated counters, statistics, or per‑core state, systems can avoid noisy shared updates and improve cache locality. This approach is especially beneficial for per‑core counters, timers, and subsystem state that is updated frequently by the corresponding CPU.

Implementation often involves reserving a per‑CPU memory region and providing declarations, allocation routines, and accessors that map to the correct per‑CPU instance. Typical mechanisms include per‑CPU declarations, per‑CPU allocation, and accessors that can target the current CPU or a specific CPU. Because the number of CPUs can change due to hotplugging, initialization and cleanup logic must handle online/offline events, and per‑CPU data may need reallocation or migration when CPUs come online or go offline.

Considerations for perCPU design include memory overhead that grows with the number of CPUs, padding to avoid false sharing by aligning data to cache lines, and careful handling of CPU affinity and migration. While perCPU data simplifies dependence on shared state, it does not remove the need for synchronization for any data that is shared across CPUs.

In practice, perCPU structures are widely used in modern kernels, notably in Linux, to underpin per‑core statistics, timers, and localized state. The concept is also mirrored in other systems where locality and scalability are important, often under different naming schemes such as per‑core or thread‑local data.