Linux Low-Latency Tuning: Hugepages, IRQ Affinity, and PREEMPT_RT

Reducing Linux Scheduling Jitter Through Hugepages, IRQ Affinity, and Real-Time Kernel Tuning

Even the fastest FPGA feed handler or kernel-bypass network stack still depends on a quiet host. When trading logic, risk checks, or residual software stages run on Linux, ordinary kernel behavior, page faults, interrupt handling, and scheduler noise can inject microseconds of jitter that erase the advantage gained in hardware.

Three techniques appear repeatedly in production low-latency environments: hugepages to stabilize memory access, IRQ affinity to keep interrupts off critical cores, and PREEMPT_RT (or equivalent real-time preemption) to bound scheduling latency. Deterministic residual latency on Linux requires explicit control of memory layout via hugepages, isolation of interrupt load through IRQ affinity, and a kernel capable of bounded preemption so that critical threads are not delayed by unbounded kernel work.

Why Default Linux Is Noisy

A stock distribution kernel optimizes for throughput, fairness, and power efficiency. Transparent huge pages may collapse or split under load, producing latency spikes. Interrupts from the network, storage, and timers land on whatever core the hardware or default affinity chooses.

The scheduler can preempt a trading thread for housekeeping, RCU callbacks, or a competing process. None of these events is wrong for a general-purpose server; each is hostile to a residual budget measured in microseconds or less. Tuning therefore begins by removing sources of non-determinism rather than by chasing average-case speed.

Hugepages: Reducing TLB and Allocation Jitter

Ordinary 4 KiB pages create two problems for latency-sensitive code. First, a large working set generates frequent TLB misses; each miss costs cycles and can stall the pipeline. Second, page-fault handling and transparent-huge-page compaction introduce unpredictable delays.

Explicit hugepages (typically 2 MiB, sometimes 1 GiB) reduce the number of TLB entries required and allow the application to pre-allocate and lock its memory. Once the pages are reserved at boot or via hugeadm/hugetlbfs and the process has called mlock or mlockall, subsequent accesses avoid both major faults and most compaction activity.

Best practice in trading systems is to disable transparent huge pages entirely (echo never > /sys/kernel/mm/transparent_hugepage/enabled) and to use explicit hugepages only for the regions that matter: order books, market-data buffers, strategy state, and lock-free queues. Overuse of hugepages wastes memory and can increase allocation time at start-up; underuse leaves TLB pressure on the hot path.

IRQ Affinity: Keeping Interrupts Off Critical Cores

Every interrupt steals cycles from the core that handles it. Network IRQs are especially dangerous: under market-data storms, the interrupt rate rises exactly when the trading threads need the CPU most.

IRQ affinity lets the administrator bind specific interrupt lines to specific cores. The usual pattern isolates a set of cores for the residual-critical threads ([isolcpus](https://www.shenglisoft.com/en/blog/low-latency-server-bios-tuning-isolcpus-numa-pinning-c-states-irq-affinity/), nohz_full, rcu_nocbs) and steers all non-essential IRQs, including most network, storage, and timer interrupts, onto the remaining cores. The critical cores then run only the pinned trading threads and the handful of IRQs deliberately assigned to them (often none).

Modern NICs with multiple queues support receive-side scaling (RSS) and can be configured so that each queue's interrupt lands on a chosen core. Combining queue steering with IRQ affinity keeps both the interrupt handler and the subsequent soft-IRQ or NAPI processing away from the hot path.

PREEMPT_RT and Bounded Scheduling Latency

The PREEMPT_RT patch set (now largely mainlined) converts most spinlocks into preemptible mutexes and thread interrupt handlers and makes the kernel capable of bounded scheduling latency. On a properly configured RT kernel, a high-priority SCHED_FIFO or SCHED_RR thread can be scheduled within tens of microseconds even when the system is under load, far tighter than a conventional kernel under the same conditions.

PREEMPT_RT is not a universal requirement. Many trading firms achieve acceptable jitter with a tuned non-RT kernel that uses core isolation, nohz_full, IRQ affinity, and careful CPU-frequency and idle-state settings. RT becomes valuable when the residual software path must guarantee a hard upper bound, when mixed workloads share the machine, or when interrupt-heavy devices cannot be fully isolated. The cost is a modest increase in average overhead and the need to validate every driver and library under the RT configuration.

Putting the Pieces Together

A typical low-latency Linux recipe therefore combines:

• Boot-time isolation of cores and redirection of RCU and timer noise.
• Explicit hugepage reservation and memory locking for the critical working set.
• IRQ affinity (and NIC queue affinity) that keeps interrupt load off the isolated cores.
• Real-time scheduling policy for the residual trading threads.
• Optional PREEMPT_RT kernel when bounded preemption is required.

Each layer removes a different source of jitter. Omitting any one of them leaves a residual path that is fast on average yet occasionally slow exactly when the market is moving.

Interaction with Kernel-Bypass and FPGA Paths

Kernel-bypass frameworks (DPDK, Onload, AF_XDP, etc.) and FPGA cards reduce the amount of work that must touch the Linux network stack. They do not eliminate the need for host tuning. The threads that consume DMA-ed descriptors, run residual strategy logic, or perform software risk checks still execute on Linux cores.

Those cores must remain quiet. Hugepages keep the descriptor rings and book state resident; IRQ affinity prevents the NIC's remaining interrupts from disturbing them; RT or careful isolation keeps the scheduler from inserting unbounded delays.

ShengliSoft and the Tuned Host

ShengliSoft's FPGA feed handlers, risk engines, and trading systems operate alongside host software that still requires a deterministic execution environment. Whether the residual path is a thin software layer above an FPGA card or a fuller software stack on a tuned server, the same Linux disciplines apply.

A host that has been configured with isolated cores, explicit hugepages, and controlled interrupt placement allows the software components to meet residual-latency targets that match the determinism of the hardware path.

Measurement and Validation

Tuning is incomplete without measurement. Tools such as cyclictest, hwlatdetect, and application-level latency histograms under both quiet and storm conditions reveal whether the changes actually reduced the tail. Comparing distributions before and after each tuning step prevents cargo-cult configuration and documents the residual budget the system can realistically claim.

Quiet Cores, Stable Memory, and Bounded Preemption Keep Software Residuals Predictable

Hugepages, IRQ affinity, and PREEMPT_RT address three distinct sources of Linux jitter: TLB and page-fault noise, interrupt interference, and unbounded scheduling delays. When they are applied together with core isolation and disciplined measurement, the host ceases to be the hidden variable in the residual latency equation.

Trading systems that treat Linux tuning as a first-class design constraint, rather than a one-time operations checklist, preserve the determinism that both pure-software and hybrid FPGA architectures require.

FAQ

1. Why disable transparent huge pages?

THP can trigger compaction and page splitting under load, injecting multi-microsecond stalls into the hot path. Explicit hugepages give controlled, pre-faulted memory without that risk.

2. What does IRQ affinity achieve?

It moves interrupt handling off the cores that run residual-critical trading threads, preventing network or device interrupts from stealing cycles at the wrong moment.

3. Is PREEMPT_RT mandatory for low-latency trading?

No. Many systems reach acceptable tails with isolation, nohz_full and IRQ affinity alone. RT is used when a hard upper bound on scheduling latency is required.

4. How do hugepages help trading engines?

They reduce TLB misses and eliminate most runtime page faults for the large, long-lived structures (books, queues, buffers) that dominate the residual path.

5. Where should network IRQs be placed?

On non-isolated cores, or on cores deliberately chosen so that both the interrupt handler and any follow-on processing stay away from the critical trading threads.

6. How does this tuning interact with FPGA cards?

FPGA paths still hand data to host threads via DMA or shared memory; those host threads need quiet cores and stable memory to avoid re-introducing jitter.

7. What is the role of core isolation?

isolcpus / nohz_full / rcu_nocbs removes scheduler and timer noise from the cores that will run the residual-critical threads, giving IRQ affinity and RT policies a clean environment to work in.

8. How should the effectiveness of tuning be verified?

By measuring scheduling and application latency distributions under representative load before and after each change, confirming that the tail, not only the average, has improved.

Disclaimer

This content is for informational purposes only and does not constitute investment advice. Financial markets and technology investments carry risk. Please conduct your own research before making investment or business decisions.