A 128-core server doing the work of 20 cores Today we put a 128-core ARM server through the Linux page fault path and got a result that should bother anyone who buys hardware by core count. The setup was simple. One benchmark, will-it-scale's page fault test. One worker per core. We started at a single core and kept adding more until all 128 were running. Up to 8 cores, everything was fine. Throughput climbed the way you would expect. Then it stopped. From 8 cores to 32, throughput went flat at about 4.5 million faults per second. Not slower. Not faster. Flat. The extra 24 cores were fully busy, burning nearly six times the kernel CPU time, and producing nothing. A profile of those cores showed spinlocks and memory accounting, not page faults. Then something stranger happened. At 33 cores, throughput started climbing again. The reason is the chip's layout. This processor is a single socket, but inside it there are four NUMA nodes of 32 cores each. Whatever the kernel was fighting over lives inside a node. Cross into the next node and you get a fresh copy of it, and a fresh 4.5 million faults per second. So the final curve climbs in four clean steps: 4.5, 9, 13.5, 18 million. Perfectly linear, if you count NUMA nodes. About 15% efficient, if you count cores. Same machine. Same run. Two opposite conclusions, depending on the unit. Full data, charts, and perf profiles in the post: multikernel.io/2026/08/21/pa… #Linux #LinuxKernel #ARM #NUMA #Performance