Why Should You Care About False Sharing?

Every performance-sensitive piece of software you will write in this free Linux kernel development course — a kernel module, a network driver’s per-packet counters, a real-time embedded control loop — eventually touches shared memory from more than one CPU core. If two threads on two different cores keep stepping on each other’s cachelines, your carefully lock-free, race-free code can end up slower than a single-threaded version. Understanding false sharing is what separates “it compiles and runs” from “it actually scales.”

A Quick Refresher: What Is a CPU Cacheline?

Modern CPUs never move a single byte between RAM and the CPU. Instead, memory is transferred in fixed-size chunks called cachelines, almost always 64 bytes on current x86-64 and ARM64 cores. When your code reads one byte of a variable, the hardware silently pulls in the entire 64-byte block that byte belongs to, and stores it in the L1 cache of that core. This is great for performance when your code accesses nearby data together (this is called spatial locality) — but it becomes a problem when two variables that are logically unrelated happen to land in the same 64-byte block.

Cache Coherency: How Multiple Cores Stay in Sync

On a multicore chip, every core has its own private L1 (and usually L2) cache, plus a shared L3 cache. If Core 0 and Core 1 both keep a copy of the same cacheline, the hardware must guarantee that neither core ever reads a stale value. This guarantee is called cache coherency, and it is implemented through a hardware protocol (commonly a MESI-family protocol — Modified, Exclusive, Shared, Invalid) that tracks the state of every cacheline in every core’s cache.

The rule the hardware enforces is simple: the instant one core modifies a cacheline, every other core’s copy of that same cacheline must be invalidated and re-fetched before it can be used again. This is completely automatic and completely correct — you never see a torn or stale value. The catch is that this invalidate-and-refetch dance is not free. It costs cycles, and it generates traffic on the interconnect between cores.

What Exactly Is False Sharing?

False sharing happens when two (or more) independent, unrelated variables that are never accessed by the same thread still end up sharing one cacheline purely due to memory layout, and are then written to concurrently by different cores. There is no logical data race — each thread owns its own variable — but the hardware still treats the whole cacheline as one unit, so every write from one core forces an invalidation that the other core pays for. The word “false” refers to the fact that the sharing is an artifact of layout, not of the program’s actual data dependencies.

This is different from true sharing, where two threads genuinely operate on the same variable and need a lock. False sharing needs no lock to fix — it needs better memory layout.

A Minimal Example

Here is a small, self-contained example you can compile and measure yourself. Two threads each increment their own private counter a huge number of times, with no shared state in the logical sense.

struct counters {
    long a;   /* touched only by thread 0 */
    long b;   /* touched only by thread 1 */
};

struct counters shared = {0, 0};

void *worker_a(void *arg) {
    for (long i = 0; i < 500000000L; i++)
        shared.a++;
    return NULL;
}

void *worker_b(void *arg) {
    for (long i = 0; i < 500000000L; i++)
        shared.b++;
    return NULL;
}

Because a and b sit only 8 bytes apart inside the same struct, they almost certainly fall in the same 64-byte cacheline, and each thread’s increments keep evicting the other core’s copy. Measured on a typical multicore Linux box, this version can run several times slower than the fixed version below, even though nothing about the algorithm changed.

Detecting False Sharing on a Modern Kernel

On kernel 6.12 and later, the standard way to actually see false sharing (instead of guessing) is the perf c2c (“cache-to-cache”) subcommand of the Linux perf tool, which is built specifically to surface cacheline contention between cores using hardware performance counters.

# record cacheline contention events while your program runs
sudo perf c2c record -- ./false_sharing_demo

# generate a report sorted by contention
sudo perf c2c report

The report highlights “hot” cachelines with high HITM (Hit-Modified) counts — that is the direct fingerprint of false sharing. This is far more reliable than eyeballing source code, especially in a large kernel module or driver where the offending struct might be defined far away from where it’s actually used concurrently.

Fixing False Sharing: Padding and Alignment

The fix is always the same idea: force each hot, independently-written variable onto its own cacheline so cores stop invalidating each other’s data. In modern C (C11 and later) you do this with alignas, or with compiler attributes.

#include <stdalign.h>

struct counters {
    alignas(64) long a;   /* now on its own cacheline */
    alignas(64) long b;   /* now on its own cacheline */
};

Inside the Linux kernel source tree itself, the same technique is used constantly, but through kernel-provided macros rather than raw alignas, so the layout stays portable across architectures with different cacheline sizes:

struct my_driver_stats {
    atomic_t rx_packets;
} ____cacheline_aligned_in_smp;

The ____cacheline_aligned_in_smp attribute (defined in include/linux/cache.h) pads and aligns a structure to SMP_CACHE_BYTES, which the kernel derives per-architecture at build time. You’ll find this pattern throughout core kernel data structures wherever a field is updated frequently by one CPU while a neighboring field is updated frequently by another — for example around per-CPU run-queue statistics in the scheduler and around hot spinlocks in networking and memory-management code.

Common Mistakes and Troubleshooting

Best Practices

• Group fields that are read together on the same cacheline (this helps performance).
• Separate fields that are written concurrently by different cores onto different cachelines.
• Prefer per-CPU data over shared, padded counters when the value genuinely differs per core.
• Always measure with perf c2c or similar hardware-counter tooling before and after any layout change.
• Re-check cacheline layout after adding new fields to a hot struct — false sharing can be introduced by an innocent-looking new field months later.

Performance Considerations

False sharing gets dramatically worse as core count increases, because more cores means more copies of the same cacheline bouncing around the interconnect. On an embedded dual-core SoC the effect might be a modest slowdown; on a 32-core or 64-core server-class part running kernel networking or scheduler code, an unpadded hot struct can become a scalability wall that limits throughput no matter how many cores you add. This is exactly why the Linux kernel’s cache-line-aware padding matters more, not less, as core counts keep climbing.

Real-World Use Case

A very common place this bites people in driver development is a small “statistics” struct with adjacent packet counters, one incremented by the receive interrupt handler on one CPU and another incremented by the transmit path pinned to a different CPU. Nothing about the code is wrong, yet under load the driver’s throughput plateaus well below the link’s theoretical bandwidth. Cache-line-aware layout (or switching to true per-CPU counters) is the standard fix applied in real kernel drivers.

Conclusion

False sharing is one of those topics that separates intermediate systems programmers from people who can genuinely make multicore Linux kernel code scale. The good news is that once you understand cachelines and cache coherency, spotting and fixing false sharing becomes a routine part of writing performance-sensitive kernel modules, drivers, and embedded C code. In the next lecture of this free Linux kernel development course, we take the natural next step: per-CPU variables, which sidestep false sharing entirely by giving each core its own private copy of hot data.

Frequently Asked Questions