Tuned vs Manual Sysctl Ownership Conflict in RHEL Latency‑Performance Profile

Goal

Determine the effective configuration for latency‑critical knobs before applying any optimization in a RHEL system.

Constraints

The latency‑performance profile from tuned writes a curated set of sysctl and kernel‑cmdline values at activation, while manual sysctl changes live in /etc/sysctl.d and boot‑time isolation knobs live in the kernel command line. Each layer can overwrite the other, yet no single manifest records the source of a value, making auditing difficult.

Unresolved Decision

Which configuration layer should own a particular knob when both tuned and manual settings are present? The effective value is whichever mechanism applied last, with no built‑in reconciliation or warning, leading to potential configuration drift after a reboot or profile switch.

Questions

1. How can we reliably discover the current owner (tuned, sysctl.d, or kernel cmdline) of a specific knob in a running system?
2. What tooling or workflow can prevent tuned from silently overwriting manual sysctl settings during profile activation?
3. Is there a recommended approach to combine tuned's latency‑performance profile with custom boot‑time isolation parameters without inducing configuration drift?