Latency limits of RHEL cpu-partitioning when kernel threads remain on isolated CPUs

The tuned cpu-partitioning profile in Red Hat Enterprise Linux is a documented mechanism for reducing scheduler and interrupt interference on designated CPUs for latency-sensitive workloads. The goal is to minimize tail latency when multiple concurrent requests contend for CPU resources.

The profile removes user-space scheduler load from isolated CPUs, but it does not automatically relocate kernel threads or hardware interrupts. Administrators must manually configure IRQ affinity and decide how to handle housekeeping tasks. Red Hat presents optional kernel boot parameters such as nohz_full and rcu_nocbs as complements, yet does not provide a definitive decision tree for when each is necessary.

Because isolation effectiveness depends on hardware topology, driver behavior, and the specific concurrent workload, identical configurations can produce different latency outcomes across systems. The unresolved behavior is whether kernel threads and RCU callbacks should remain on isolated CPUs or be explicitly offloaded, as Red Hat support does not prescribe one universal approach.

Should kernel threads and RCU callbacks be explicitly moved off CPUs isolated by cpu-partitioning to avoid latency spikes under concurrent load, or is retaining them acceptable for certain workloads? How does the absence of an automatic relocation mechanism affect the support boundary for latency-sensitive deployments? Is there a documented threshold where aggressive IRQ pinning to free isolated CPUs begins to degrade latency on the remaining housekeeping processors?