CPU Pinning and Core Isolation

By default, an operating system treats CPU cores as an interchangeable pool: a thread runs on whichever core is free, and the scheduler will happily move it to a different core moments later if that helps balance load across the machine. For most software this is exactly the right behavior — it keeps the whole system efficient without any programmer intervention. For a latency-critical trading thread, that same helpfulness is a source of unpredictable delay: every time the scheduler decides to run something else on your core, or migrates your thread to a different one, you pay a jitter-inducing pause that has nothing to do with your code's actual work.

CPU pinning (also called CPU affinity) fixes a specific thread to a specific core, telling the OS scheduler "never run this thread anywhere else." That alone helps — no migration cost, and the thread's data stays warm in that core's private cache instead of needing to migrate along with it. But pinning a thread to a core doesn't stop other threads and OS housekeeping tasks from also landing on that same core and interrupting it. The stronger tool is core isolation: at boot time, tell the OS to exclude certain cores from its normal scheduling pool entirely (Linux's isolcpus boot parameter is the classic example), so ordinary processes, background daemons, and even most interrupt handling are steered away from them by default. Pin your latency-critical thread to one of these isolated cores, and it effectively gets the core to itself — nothing else competes for its cache, its instruction pipeline, or its CPU time.

Worked example: eliminating a scheduling-induced spike

A market-data thread runs unpinned on a general-purpose core and has a p99.9 latency of 40 microseconds, driven almost entirely by occasional pauses when the scheduler runs a different process (a logging daemon, a monitoring agent) on the same core for a few milliseconds' worth of scheduling quantum. After pinning the thread to an isolated core (excluded from the general scheduler and with interrupt routing for other devices steered elsewhere), the same workload's p99.9 drops to under 500 nanoseconds — nearly two orders of magnitude better — because the thread simply never gets interrupted by anything else wanting that core. The median latency barely changes; the entire improvement comes from eliminating the rare but large scheduling-induced stalls that dominated the tail.

What this means in practice

Pinning and isolation are typically reserved for a handful of the most latency-critical threads — market-data ingestion, the order-send path — since a machine only has so many cores and isolating too many starves the rest of the system. They pair naturally with busy polling (an isolated core is what makes busy polling worthwhile) and with NUMA-aware memory allocation (pinning a thread to a core on the wrong NUMA node can add latency the pinning was meant to remove). Verifying isolation actually worked — checking that no unexpected process lands on the isolated core — is itself a standard part of deploying a low-latency trading system.