CPU tuning in the QM partition

CPU tuning in the QM partition¶

CPU tuning maximizes the responsiveness and efficiency of an operating system to optimize system performance.

Carefully consider the underlying architecture, workload characteristics, and scheduling policies of your operating system before tuning parameters such as CPU throttling, CPU weight, and CPU affinity. Arbitrary changes to these values can lead to unintended consequences, including degraded system performance, priority inversion, increased latency, starvation of system-critical tasks, or even system deadlock. You must validate any modifications to CPU parameters in a controlled environment before deploying them to production systems.

CPU prioritization and preemption : You can use various CPU schedulers simultaneously on a system. There are generally two categories of schedulers: real-time (RT) and non-real-time (non-RT).

* RT schedulers use explicit process prioritization. An RT process maintains exclusive access to CPU resources unless
preempted by a higher-priority RT process. Lower-priority and non-RT processes can also be scheduled on the CPU any time the
higher-priority RT process is not actively using the CPU, such as during sleep or I/O operations.
* Non-RT schedulers always share access to the CPU; they never have exclusive access. A weighting mechanism known as a `nice`
value determines how much access to system resources one non-RT process gets relative to another. A lower `nice` value equals more access to
CPU resources, and a higher `nice` value equals less access to CPU resources. A non-RT process always has a lower scheduling priority than an
RT process, except in the case of throttling.

CPU throttling : Throttling is an essential safeguard in Linux-based operating systems that ensures system-critical workloads are prioritized and processed reliably.

By default, the real-time Linux kernel implements a scheduling and throttling mechanism on a per-core basis within the CPU.
Throttling is isolated to individual cores, ensuring that task scheduling on one core does not affect task scheduling on other cores.

With throttling enabled, the scheduler throttling mechanism allocates 95% of a core's time slice to the highest priority RT
tasks. The system reserves the remaining 5% of time to ensure that system-critical processes can preempt RT processes.

More specifically, RT processes get 950ms every second and are preempted for 50ms to allow scheduling of system-critical, non-RT processes.
This preemption pauses the RT processes regardless of whether there are any critical processes waiting for CPU time.

When throttling is enabled, users will always observe increased latency due to the 5% allocation for critical processes.

Disabling throttling is an important part of explicit RT scheduling control, but only expert users who fully understand the impact of
their configuration should disable throttling.

CPU weight : CPUWeight is an attribute you can set for hierarchical Linux kernel systemd control groups (cgroups). CPUWeight settings govern the CPU controller within the cgroup hierarchy. CPUWeight splits the available CPU time among all units within one slice relative to their CPU time weight. A higher weight means more CPU time, a lower weight means less.

You can configure `CPUWeight` in the
[QM section](https://centos.gitlab.io/automotive/src/automotive-image-builder/simple_manifest.html#qm_cpu_weight) of your
Automotive Image Builder manifest file.

CPU affinity : CPUAffinity is an attribute you can set to specify which specific CPUs are available to specific processes. CPU affinity, also known as CPU pinning, sets a process or thread to run only on CPU cores that you designate.

Processes compete for resources, including CPU time. CPU pinning isolates an RT-sensitive task from resource contention and
ensures deterministic performance. Setting CPU affinity is an effective way to maximize system performance by ensuring high priority
processes have the resources required to run.

You can configure `CPUAffinity` by creating systemd `.service` files and adding them to the QM section of your
Automotive Image Builder manifest file.

Additional resources