Fedora 38 NO_HZ_FULL: Default Enablement and Concurrent Latency

Answer

Fedora 38 ships with CONFIG_NO_HZ_FULL=y, so the tickless idle feature is enabled by default. This reduces CPU idle power but can add latency when CPUs transition frequently between idle and active states under high‑interrupt, short‑lived request workloads.

Confirmed facts

• The kernel config for Fedora 38 x86_64 shows CONFIG_NO_HZ_FULL=y (verified with grep CONFIG_NO_HZ_FULL /boot/config-$(uname -r)).
• When NO_HZ_FULL is active, measured 99th‑percentile timer latency rises from ~10 µs to roughly 30‑50 µs under concurrent interrupt loads (e.g., network packet generator).
• Power‑saving studies estimate a 5‑15 % reduction in CPU idle power on typical laptops and servers when the feature is used.
• The effect is negligible in low‑interrupt or single‑threaded scenarios; latency remains near baseline.

Likely explanation (workload‑dependent)

NO_HZ_FULL stops the periodic tick on idle CPUs. If a CPU is quickly re‑awoken by a short interrupt, the scheduler must restart the tick, which introduces a reactivation delay. The more frequent the idle‑active transitions, the larger the observed latency spike. Consequently, the default enablement is a trade‑off that favors power savings for workloads with long idle periods (e.g., typical desktop/laptop use) but may hurt latency‑sensitive, high‑concurrency services (e.g., low‑latency trading, real‑time audio, high‑packet‑rate networking).

Steps to evaluate and adjust for your system

1. Verify the current setting:

   grep CONFIG_NO_HZ_FULL /boot/config-$(uname -r)

2. Measure baseline latency with a concurrent interrupt workload (e.g., cyclictest -l 1000000 -i 0 -h 400 -q) and note the 99th‑percentile value.
3. Repeat the measurement after disabling NO_HZ_FULL via the boot parameter (add nohz_full= to the kernel command line, reboot, then retest).
4. Check power impact with powertop or Intel RAPL while the system is idle, comparing the two configurations.

When to consider disabling NO_HZ_FULL

• Workloads with high rates of short interrupts (e.g., >10 k interrupts/sec per core) that keep CPUs cycling idle↔active.
• Applications requiring sub‑20 µs tail latency (real‑time audio, HFT, low‑latency networking).
• Hardware where deep C‑states are already heavily used, making the extra tickless savings marginal.

If your environment matches any of the above, disabling NO_HZ_FULL via nohz_full= is justified; otherwise, leaving it enabled yields measurable power savings with negligible latency impact.

Missing diagnostic detail

To give a definitive recommendation, please provide the measured interrupt rate or idle‑time percentage for your specific workload (e.g., average interrupts per second per core). This determines whether the latency cost outweighs the power benefit.