What is impact of SMT (Simultaneous Multithreading) on latch spinning?
In the pursuit of 1 million TPS, SMT (Intel’s Hyper-Threading or AMD’s SMT) is often the "hidden variable" that turns a high-performance system into a bottlenecked mess.
While SMT is great for general-purpose multitasking, it creates a unique and often destructive interaction with latch spinning (spinlocks).
To understand the impact, you must remember that SMT does not give you two real cores. It gives you two architectural states (Logical Cores) sharing a single set of execution resources (ALUs, FPUs, and Caches).
Core A (Logical 0): Running your transaction logic.
Core B (Logical 1): Spinning on a latch, waiting for Core A to finish.
Because they share the same physical pipeline, the "spinning" on Core B isn't free—it consumes the very execution ports Core A needs to finish its work and release the lock.
When a thread "spins" on a latch, it executes a tight loop (usually a CMP and a JNE instruction). In an SMT environment, this creates two specific hardware contention problems:
The CPU's internal scheduler doesn't know the difference between a "useful" instruction and a "spin" instruction. If the spinning thread on Logical Core 1 is aggressive, it can saturate the Instruction Decode or Execution Ports, slowing down the "useful" work on Logical Core 0 by 30–50%.
Spinning usually involves repeatedly reading a memory address. If that address is being modified by the other thread (the lock holder), the MESI protocol (Cache Coherency) goes into overdrive. Constant cache-line "invalidations" and "shuffles" happen between the two logical cores, creating massive heat and electrical noise on the internal ring bus.
Modern CPUs attempt to mitigate this using the PAUSE instruction within the spin loop.
Without PAUSE: The spinning thread consumes maximum pipeline resources. The lock holder takes longer to finish. This is a vicious cycle.
With PAUSE: The spinning thread tells the hardware, "I am waiting; yield resources to my SMT neighbor." This de-prioritizes the spinning thread in the pipeline, allowing the lock holder to finish faster.
The 1M TPS Reality: Even with
PAUSE, the overhead of SMT context-switching at the hardware level often outweighs the benefits. Most ultra-high-frequency systems (like HFT or Tier-0 DBs) disable SMT/Hyper-Threading in the BIOS to ensure deterministic performance.
| Scenario | SMT Impact | Why? |
| I/O Bound Workload | Positive | While one thread waits for disk/network, the other uses the CPU. |
| CPU-Bound (No Contention) | Neutral/Positive | Better utilization of underused execution ports. |
| High Latch Contention | Negative | Spinning threads "steal" cycles from the threads they are waiting for. |
| 1M TPS Synchronous | Disastrous | Increases P99.9 tail latency due to unpredictable pipeline stalls. |
If you must keep SMT enabled for a 1M TPS workload, your stochastic model must change:
Adaptive Spinning: If a latch isn't acquired within $N$ cycles, the thread should yield or sleep rather than continuing to spin and starve its SMT twin.
Core Affinity: Pin your high-priority threads to physical cores (e.g., Core 0 and Core 2) rather than letting them share a physical core (Core 0 and Core 1).
For a 1M TPS workload, SMT is a double-edged sword. It increases theoretical throughput but introduces hardware-level jitter. In the world of latch spinning, SMT often creates a "tax" where the waiter inadvertently sabotages the worker.