Skip to content

Scheduling and priority in the QM partition

To prevent temporal interference and thread starvation, configure the scheduler priorities for your quality-managed (QM) partition.

Images built with Automotive Image Builder assign a lower scheduling priority to processes that run in the QM partition than critical processes that run in the root partition. However, you must tune the scheduling priorities to meet your workload requirements and minimize temporal interference without starving process threads.

  • Temporal interference occurs when the timing requirements of one task, thread, or process interfere with those of another.
  • Thread starvation occurs when a thread is on a CPU run queue for longer than the starvation threshold and does not make progress. For more information, see Thread starvation in the real-time kernel.

While you can tune scheduler priorities to minimize the likelihood of interference or starvation, you must also use an external watchdog to detect interference with critical, time-sensitive processes. For more information, see About external watchdogs.

Understanding real-time process scheduling and priority

Before you override the default scheduler priorities to configure your image, you must assess your intended operating system (OS) implementation and understand the following key concepts:

  • Your anticipated resource needs for your workloads
  • Your hardware limitations
  • Linux scheduler policies and how they rank against one another with regard to precedence and preemption
  • Linux resource management methods

Hardware and software considerations

First, consider the following operating system (OS) requirements in the context of your intended implementation:

  • Your intended hardware platform and its limitations
  • Resources necessary for the critical and QM processes you intend to run
  • How those necessary resources interact with your intended hardware

Linux scheduler policies

To appropriately configure your image for the anticipated workloads on your intended hardware, you must understand the normal and real-time scheduler policies available in Linux. The Linux scheduler has two major categories of scheduling policies:

Normal policies
Normal threads used for tasks of normal priority use the Completely Fair Scheduler (CFS). The Secure Computing Mode (seccomp) policy limits the entire QM partition container to normal scheduler policies such as SCHED_IDLE and SCHED_OTHER or SCHED_NORMAL. Real-time scheduler policies are not supported in QM partition containers.
Real-time policies
Real-time policies are for time-sensitive tasks that must complete without interruption. Real-time threads are not subject to time slicing. This means the thread runs until it blocks, exits, voluntarily yields, or a higher priority thread preempts it.

The Linux scheduler prioritizes the lowest priority real-time thread before any thread with a normal policy.

You must understand the interrelationship between the following scheduler policies:

SCHED_IDLE
This normal policy has a lower priority than SCHED_OTHER, which means processes do not run until higher priority processes are idle. Automotive Image Builder uses this policy as the default central processing unit (CPU) scheduler priority.
SCHED_OTHER or SCHED_NORMAL policy
This is the default scheduling policy for normal Linux threads. It has a dynamic priority the system changes based on the characteristics of the thread. SCHED_OTHER threads use nice values that range -20 to 19. The lowest nice value is the highest priority and has the highest access to the CPU. The default nice value is 0.
SCHED_FIFO policy
Threads with SCHED_FIFO run with higher priority over SCHED_OTHER tasks. Instead of using nice values, SCHED_FIFO uses a fixed priority between 1, which is the lowest and 99, which is the highest. A SCHED_FIFO thread with a priority of 1 always schedules before a SCHED_OTHER thread.
SCHED_DEADLINE policy
The SCHED_DEADLINE policy schedules each task according to the task’s deadline. The task with the earliest deadline runs first.

Additional resources

Configuring scheduler priority for the QM partition using Automotive Image Builder

To configure scheduler priority to minimize latency and interference, you must tune the CPUWeight for the QM partition to a value between 1 and 100.

CPUWeight is an attribute you can set for hierarchical Linux kernel systemd control groups (cgroups). It 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.

Automotive Image Builder sets default central processing unit (CPU) scheduler priority for the QM partition to CPUWeight=idle. That means processes in the QM partition do not run until critical processes running on the root partition are idle. If you use the default scheduler priority, it might starve processes in the QM partition of CPU time, so it is important that you find the optimal setting for your needs.

Prerequisites

Procedure

  • In your manifest file, set the cpu_weight for the entire QM partition to a value between 1 and 100. For example, if you were to set CPUWeight=50, all processes in your QM partition would receive half the CPU time that is available to the critical processes running on your root partition.

    Example CPUWeight
      # Override the default SCHED_IDLE scheduler policy
  # to allocate CPU time to the entire QM partition
  cpu_weight: 50

Verification

  1. Use Automotive Image Builder to build your image from the manifest:

    Example Automotive Image Builder command
       automotive-image-builder --verbose \
    build \
    --distro autosd9 \
    --target qemu \
    --mode image \
    --build-dir=_build \
    --export image \
    container_qm_scheduling.aib.yml \
    container_qm_scheduling.$arch.img

  2. Use automotive-image-runner to start your image:

    Start the image
    automotive-image-runner <my_image>.img

  3. After the image starts, log in as root using the password password.

  4. Use the systemctl show command to display the default CPUWeight and the path for the drop-in configuration file generated by the cpu_weight value you set in your manifest:

    Verify QM partition CPUWeight
    [root@localhost ~]# systemctl show qm | grep CPUWeight
CPUWeight=<value>=1_and_<=100>
StartupCPUWeigh=[not set]

  5. Review the contents of the drop-in file generated by your manifest using the cat command:

    Show drop-in configuration file contents
    [root@localhost ~]# cat /usr/share/containers/systemd/qm.container.d/10-automotive.conf
[Service]
MemoryMax=infinity
MemoryHigh=infinity
CPUWeight=50

[Container]

Additional resources

© Red Hat