How SMT Hurts Low‑Latency High‑Frequency Trading and How to Disable It on AWS

1. What Is SMT

SMT (Simultaneous Multi‑Threading), known as Intel Hyper‑Threading, lets a physical core present two (SMT2) or four (SMT4) hardware threads as separate logical CPUs. The OS schedules these logical cores independently, but only a small part of the execution state—program counter, registers, etc.—is duplicated; the rest of the core’s resources are shared.

Copied : architectural state such as the program counter and register file, giving each thread its own execution context.

Shared : front‑end fetch/decode, out‑of‑order scheduler, execution ports (ALU, FPU, load/store units), reservation stations, reorder buffer, L1/L2 caches, TLB, and memory bandwidth.

SMT’s design goal is to increase overall throughput by filling otherwise idle issue slots with a second thread, not to reduce latency.

2. Why High‑Frequency Trading Should Disable SMT

2.1 Execution Resources Are Contested

When a strategy thread runs its hot path (parsing market data, updating order books, computing signals, sending orders), a sibling logical core on the same physical core may also be active, causing both threads to compete for ALU and load/store ports. The strategy thread can be delayed by several cycles.

Shared L1/L2 caches exacerbate the problem: the neighbor thread can evict hot data, turning a cache hit into a miss and adding tens to hundreds of cycles of latency.

2.2 Unpredictable Tail Latency

Low‑latency systems care about the 99th/99.9th percentile (P99, P999) and jitter, not average latency. Because the amount of execution resources a thread receives depends on what its neighbor is doing at that moment, the same hot‑path code can take 800 ns one run and 1500 ns the next, purely due to neighbor activity.

The book Performance Analysis and Tuning on Modern CPUs notes that SMT adds extra burden for developers because it makes performance harder to predict—acceptable for typical services but not for trading systems that must guard P999 latency.

2.3 Cloud’s “Noisy Neighbor”

On shared‑CPU cloud instances, the two logical cores of a physical core may belong to different tenants or workloads. Your strategy thread then shares L1/L2 caches and execution ports with an uncontrolled neighbor, making latency spikes unacceptable in production.

2.4 Core Pinning and Isolation Become Simpler

Low‑latency setups usually pin the strategy thread to a specific core and isolate it using isolcpus and nohz_full. With SMT enabled, each physical core appears as two logical cores, so isolation must handle pairs and guard against the scheduler placing other tasks on the sibling logical core. Disabling SMT makes the mental model clean: one core, one thread, exclusive execution ports and caches.

SMT also historically enabled certain side‑channel vulnerabilities (e.g., L1TF, MDS); turning it off removes that risk, though it is a secondary concern for trading systems.

Conclusion : High‑frequency trading prioritizes deterministic low latency, while SMT trades latency for throughput. Therefore the standard practice for low‑latency machines is to disable SMT so each physical core is dedicated to a single thread.

3. Disabling SMT on AWS

The cleanest way is to set the number of threads per core to 1 in the instance’s CPU options at launch time, rather than trying to turn it off after boot.

In the AWS console, expand Advanced Details → CPU Options , check Specify CPU options , set Thread(s) per CPU core to 1, and choose the desired number of physical cores.

When Thread(s) per CPU core is set to 1, the instance shows one vCPU per physical core; with the default 2, each physical core appears as two vCPUs. Billing is based on instance type, so cost does not change, but each core’s execution resources are no longer shared.

Intel, AMD, and ARM Differences

Intel instances (e.g., c5, c6i, m6i) generally support SMT; you can choose 1 or 2 threads per core, default 2.

AMD instances may have some types that do not provide SMT at all, so the thread‑per‑core setting is fixed at 1.

AWS Graviton (ARM) instances (e.g., c6g, c7g) are designed as one‑thread‑per‑core; SMT is not available.

When selecting an instance, verify whether the type supports multiple threads per core; if it only offers 1, no further action is needed, otherwise explicitly set it to 1.

4. Verifying That SMT Is Disabled

After launch, confirm the configuration inside the VM. The Linux kernel exposes CPU topology via lscpu:

lscpu | egrep -i 'Thread|Core|Socket|On-line|Off-line'

Check the line Thread(s) per core: = 1: SMT is disabled (or the instance type lacks SMT). = 2: SMT is enabled.

On a 4‑physical‑core instance with SMT disabled, the output looks like:

Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
On-line CPU(s) list: 0-3

Only CPUs 0‑3 are online, matching the four physical cores. With SMT enabled, the same machine reports:

Thread(s) per core:  2
Core(s) per socket:  4
Socket(s):           1
On-line CPU(s) list: 0-7

Include this check in the low‑latency machine startup checklist: set threads per core to 1 at launch, run lscpu to verify, and only then deploy the trading strategy.