Reproducing the Linux 4.18 Kernel Scenario: CPU Power Management, Tuned Service Impact, and Optimization Recommendations

In the previous section we compared how Linux 2.6 and 4.18 kernels manage CPU efficiency, but to understand why their performance diverges dramatically in power‑saving mode we need to reproduce the 4.18 scenario for further analysis.

Reproducing the 4.18 Kernel Scenario

Using the power‑saving mode execution and sleep‑state results (see images below):

Using the performance mode execution and sleep‑state results (see images below):

From the outputs we can observe:

In performance mode most CPUs enter C1 state, which is expected.

In power‑saving mode no CPU enters a sleep state; all CPUs stay in C0, which is abnormal.

This raises two questions: (1) Why does the 4.18 kernel keep CPUs in C0 after enabling power‑saving mode? (2) Why do the two modes show similar CPU frequencies yet the execution time differs by almost a factor of two?

The answer to the first question lies in the system’s latency‑request setting. The culprit is the tuned service, which runs in latency‑performance mode and forces the request latency to 1 µs. Consequently the kernel selects the poll_idle state with a 0 µs wake‑up latency, which keeps the CPU busy executing NOP instructions, so the CPU never enters a deeper C‑state.

Because the wake‑up latency of C1 is 2 µs, the system prefers poll_idle (0 µs) and therefore the CPU stays in a busy loop. This busy loop does not improve performance; on the contrary, it causes the execution time to double despite similar frequencies.

Hyper‑Threading (HT) further aggravates the problem. Modern CPUs expose two logical cores per physical core, sharing a single ALU. When both logical cores are fully active, each logical core’s execution time roughly doubles, but parallel execution keeps overall runtime similar. However, if one logical core is stuck in poll_idle , the other logical core suffers a 50 % performance loss, similar to planting weeds in a field.

Why is the tuned service enabled to force this state? It was observed that a certain workload performed better with the service, so the default installation template for CentOS 7 enables tuned in latency‑performance mode. Unfortunately, in our scenario this setting degrades performance.

Tuned Service Configuration (CentOS 7 default)

The relevant CPU‑related settings are:

force_latency : system request latency (maps to /sys/kernel/debug/pm_qos/cpu_dma_latency ).

governor : P‑state policy (maps to /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ), configurable via cpupower idle‑set .

energy_perf_bias : sets CPU energy‑performance policy using x86_energy_perf_policy , influencing how aggressively the CPU enters low C‑states.

min_perf_pct : minimum P‑state frequency limit (maps to /sys/devices/system/cpu/intel_pstate/min_perf_pct ), configurable via cpupower frequency‑set .

Note that tuned may overwrite custom sysctl optimizations for scheduling and memory.

Overall Recommendation Configuration

Scenario 1: Low latency, high concurrency, and stability

For workloads requiring minimal response time, high request rates, and stable operation, the BIOS should be set to maximum performance: disable P‑states, C‑states, and MONITOR/MWAIT instructions.

Scenario 2: High compute, low concurrency, relaxed latency and stability requirements

For compute‑intensive, low‑concurrency jobs, enable power‑saving mode: turn on P‑states, C‑states, and MONITOR/MWAIT, and also enable Turbo Boost. If the tuned service is in latency‑performance mode, it effectively forces Scenario 1 settings, so either disable the service or switch to a more appropriate profile (e.g., network‑latency or throughput‑performance ).

Conclusion

The main difficulty when using the 4.18 kernel is the lack of debuginfo packages, which hampers crash analysis. Nonetheless, the best‑practice recommendations above should help most users tune their systems effectively, while acknowledging that specific workloads may require further fine‑tuning.