Independent CPU Data Can Still Contend: Why False Sharing Limits Core Scaling

The coherence unit can be larger than the value being updated

Imagine CPU workers preparing separate requests for a GPU. Each worker maintains its own progress value, and neither worker needs the other's value. That description establishes logical separation. It leaves the values' placement in memory unspecified.

A cache line is a block managed by the cache hierarchy. In a coherent system, multiple caches' copies must be coordinated when writes occur. Arm's December 13, 2024 discussion of MESI-based coherence explains that a writer needs exclusive access to the line, invalidating other cached copies; subsequent readers can make the line migrate or lose that exclusivity.

Consequently, another core accessing a different value in that line can encounter coherence work caused by its neighbor's writes. This is false sharing. The actual transaction path and cost depend on the processor and access sequence; a source-level assignment is not a count of line transfers or DRAM accesses.

References: [CC1][FS3]

FS-211: two independent 8-byte items share line 0

FS-211 is an invented address-layout comparison. Stipulate two physical cores, coherent private caches and a 64-byte line grid whose aligned origin is address 0. Line 0 covers addresses 0–63, line 1 covers 64–127, and subsequent lines follow the same grid. This line size is an example assumption, not a specification for every CPU.

A occupies bytes 0–7. B occupies bytes 8–15. Core 0 repeatedly updates only A, and core 1 repeatedly updates only B. Stipulate valid, nonoverlapping objects, completed initialization and no other accesses to these objects or lines during the comparison. The updates occur as memory accesses; this is not a prediction about how a compiler implements a particular loop.

Both ranges lie inside 0–63, so both items occupy line 0. The useful payload is 8 + 8 = 16 bytes. Disjoint addresses have not created disjoint coherence units.

Consider core 0 obtaining write access to line 0 and updating A. Core 1 later needs write access to that same line to update B. Under the stipulated coherent arrangement, their accesses can require changes in line ownership and cached-copy validity. Core 0's next update may then face the same interaction in the opposite direction. The coupling follows from the line containing both items, although neither worker updates the other's value.

References: [CC1][FS3]

Change the line relationship without changing useful payload

In FS-211's comparison layout, keep A at bytes 0–7 and place B at bytes 64–71. A is now wholly in line 0 and B wholly in line 1. Keep the two cores and each item's update ownership unchanged.

The payload remains 16 bytes. The address span from the first occupied byte through the last grows from 16 to 72 bytes, and the two items now touch two lines instead of one. That address-span calculation is not a claim about an allocator's requested or reserved size.

For these two items under these assumptions, B's writes no longer need the line containing A. The comparison removes their shared-line relationship. It does not specify the number of transfers in either layout, total cache occupancy, elapsed time or a throughput improvement.

Now change the original packed case so that both cores merely read the initialized, unchanging values, with no writes or other ownership-changing activity. The write-induced interaction described here is absent. First accesses and other cache misses can still occur. Conversely, a writer beside a reader can be enough: the kernel documentation illustrates a changing reference count sharing a line with an unchanged name read by other CPUs.

References: [FS1][CC1]

Keep false sharing separate from sharing the same value

If both workers update one common progress counter, they genuinely share the value. That is true sharing. Giving that counter a line of its own does not remove the workers' need to coordinate access to the counter itself. Intel's 2011 multithreading guide distinguishes this case from workers accessing different variables in one line.

Correctness is another question. The C++ working draft defines conflicting evaluations around the same memory location or overlapping object lifetime, then defines a data race through concurrency, atomicity and ordering conditions. Merely occupying one cache line is not that definition.

FS-211 stipulates separate valid objects and exclusive update ownership for each. Its purpose is to show how independent accesses can still interact through coherence, without positing a data race between those accesses. A real program still needs its own correctness assessment. Likewise, correctly synchronized access to a genuinely shared value may remain expensive; correctness does not certify scaling.

References: [FS3][DR1]

A 64-byte record is not automatically isolated

Intel's VTune Cookbook at the 2024.2 URL retains a historical scenario using VTune Amplifier 2018, Ubuntu 16.04 64-bit and a Core i7-6700K. Its sample has independent threads accessing their own array elements. Each sample record is 64 bytes, matching that scenario's cache-line size, but the array's base alignment can let neighboring elements cross line boundaries.

An original illustration uses FS-211's stipulated grid with different objects: record X is 64 bytes at addresses 16–79, followed by 64-byte record Y at 80–143. Line 1, covering 64–127, contains X's last 16 bytes and Y's first 48 bytes. Equal record and line sizes have not prevented overlap at line granularity. Whether accesses contend also depends on which fields are actually accessed and written.

The buyer therefore needs the implemented layout and access relationship, rather than a statement that each record is 64 bytes. Intel's historical example establishes the alignment hazard; its timings do not forecast a current server's result.

References: [FS2]

More cores, RAM and cache answer different questions

The interaction in FS-211 is caused by coherence rather than a working set exceeding cache capacity. Extra DRAM would not change which line contains A and B in the packed layout. A larger nominal cache would not, by itself, give two cores simultaneous independent write ownership of that same line. A capacity miss concerns data that cannot all be retained in the relevant cache; false sharing concerns interference from accesses to different data in one coherence unit. Both can occur in one workload.

Adding cores can introduce more participants accessing the same lines. It does not divide an existing line into independently owned values. Whether additional cores improve useful throughput remains a workload question; a scaling plateau alone cannot identify false sharing as its cause.

NUMA describes the relationship between execution location and main-memory placement. Linux's NUMA primer explains that cache-coherent NUMA systems can provide shared addressability while local and remote access paths differ. That placement question remains distinct from two values sharing a line, even when the cores are in one locality domain.

SMT concerns hardware threads sharing one core's execution resources. Intel's Xeon explanation supplies that distinction. FS-211 deliberately uses two physical cores, so its mechanism does not require SMT siblings competing within one core. Use the related topology and NUMA articles for those separate offer questions.

References: [FS3][CC1][NM1][HT1]

A different layout or write pattern has tradeoffs

Conceptual responses include separating independently written data and reducing how often shared structures receive writes. Those choices can increase space use, consume more cache lines or add complexity to how results become visible. A denser arrangement can remain sensible for infrequently accessed data.

The unversioned kernel documentation, checked October 20, 2026, explicitly weighs mitigation against space and complexity. It also warns that removing one hotspot may leave overall performance little improved because another becomes limiting. The choice belongs to the application owner, with correctness and representative performance evidence considered together. FS-211 is an explanation of placement, not an allocation or padding recipe.

References: [FS1]

Ask what the proposed core increase actually demonstrated

Suppose one GPU-host proposal offers more CPU cores and predicts a proportional increase in request throughput because each worker processes a different request. FS-211 shows the missing premise: request independence does not establish independent access at cache-line granularity. The proposal remains a hypothesis until evidence connects the offered configuration to useful work.

Ask the platform and application owners for a representative scaling comparison identifying the exact server and processor, physical cores and enabled SMT, CPU resources available to the workload, memory arrangement, software build and concurrent activity. The workload description should identify the CPU stage, useful output, input mix, request size and timing criterion. For a feeding stage, assess its contribution to the intended GPU workflow as well as its isolated completion time.

For the false-sharing explanation specifically, ask which independently used values share lines, which participants write them, how often those accesses occur, and what evidence connects that activity to lost progress. Intel's historical guide cautions that evidence of cache-line sharing alone does not distinguish true from false sharing. A generic memory-bound label or aggregate CPU utilization therefore leaves the ownership question unanswered.

If a comparison changes data layout or update behavior as well as hardware, retain that distinction in the result. A gain from two simultaneous changes cannot, by itself, be credited entirely to additional cores. Evidence from a read-only case also leaves the application's write-heavy case unresolved.

Use the result to decide whether the proposed system meets the required throughput and response time, whether a core upgrade is supported, or whether the scaling claim remains unproven. Neither FS-211 nor a historical tuning example supplies a universal performance multiplier.

References: [FS3]

Carry selected hardware into a physical installation brief

If the resulting hardware choice creates an installation project, Leviathan's rack-and-stack service and project inquiry below provide the relevant next step. The published scope covers agreed equipment mounting, IT cabling, labels and physical installation records.

Share the selected equipment, site, released rack positions, connection requirements and required handoff records to discuss physical scope and availability. Application tuning, coherence analysis and workload performance acceptance remain with the appointed platform and application owners.

References: [L1]