Red Hat SummitChapter 7. Scheduling policies for RHEL for Real Time
In real-time, the scheduler is the kernel component that determines the runnable thread to run. Each thread has an associated scheduling policy and a static scheduling priority, known as sched_priority. The scheduling is preemptive and therefore the currently running thread stops when a thread with a higher static priority gets ready to run. The running thread then returns to the waitlist for its static priority.
All Linux threads have one of the following scheduling policies:
-
SCHED_OTHERorSCHED_NORMAL: is the default policy. -
SCHED_BATCH: is similar toSCHED_OTHER, but with incremental orientation. -
SCHED_IDLE: is the policy with lower priority thanSCHED_OTHER. -
SCHED_FIFO: is the first in and first out real-time policy. -
SCHED_RR: is the round-robin real-time policy. -
SCHED_DEADLINE: is a scheduler policy to prioritize tasks according to the job deadline. The job with the earliest absolute deadline runs first.
7.1. Scheduler policies
The real-time threads have higher priority than the standard threads. The policies have scheduling priority values that range from the minimum value of 1 to the maximum value of 99.
The following policies are critical to real-time:
SCHED_OTHERorSCHED_NORMALpolicyThis is the default scheduling policy for Linux threads. It has a dynamic priority that is changed by the system based on the characteristics of the thread.
SCHED_OTHERthreads have nice values between -20, which is the highest priority and 19, which is the lowest priority. The default nice value forSCHED_OTHERthreads is 0.SCHED_FIFOpolicyThreads with
SCHED_FIFOrun with higher priority overSCHED_OTHERtasks. Instead of using nice values,SCHED_FIFOuses a fixed priority between 1, which is the lowest and 99, which is the highest. ASCHED_FIFOthread with a priority of 1 always schedules first over aSCHED_OTHERthread.SCHED_RRpolicyThe
SCHED_RRpolicy is similar to theSCHED_FIFOpolicy. The threads of equal priority are scheduled in a round-robin fashion.SCHED_FIFOandSCHED_RRthreads run until one of the following events occurs:- The thread goes to sleep or waits for an event.
A higher-priority real-time thread gets ready to run.
Unless one of the above events occurs, the threads run indefinitely on the specified processor, while the lower-priority threads remain in the queue waiting to run. This might cause the system service threads to be resident and prevent being swapped out and fail the filesystem data flushing.
SCHED_DEADLINEpolicyThe
SCHED_DEADLINEpolicy specifies the timing requirements. It schedules each task according to the task’s deadline. The task with the earliest deadline first (EDF) schedule runs first.The kernel requires
runtime⇐deadline⇐periodto be true. The relation between the required options isruntime⇐deadline⇐period.
7.2. Parameters for SCHED_DEADLINE policy
Each SCHED_DEADLINE task is characterized by period, runtime, and deadline parameters. The values for these parameters are integers of nanoseconds.
| Parameter | Description |
|---|---|
|
|
For example, if a video processing task has 60 frames per second to process, a new frame is queued for service every 16 milliseconds. Therefore, the |
|
|
For example, if a video processing tool can take, in the worst case, five milliseconds to process an image, the |
|
|
For example, if a task needs to deliver the processed frame within ten milliseconds, the |
7.3. Configuring SCHED_DEADLINE parameters
The sched_deadline_period_max_us and sched_deadline_period_min_us parameters in Red Hat Enterprise Linux are kernel tunable parameters of SCHED_DEADLINE scheduling policy. These parameters control the maximum and minimum allowed period in microseconds for tasks by using this real-time scheduling class.
sched_deadline_period_max_us and sched_deadline_period_min_us work together to define an acceptable range for the period values of SCHED_DEADLINE tasks.
-
The
min_usprevents high-frequency tasks that might be using excessive resources. -
The
max_usprevents extremely long-period tasks that might lead to under-performance of other tasks.
Use the default configuration of parameters. If you need to change the values of parameters, you must test the custom values before configuring them in live environments.
The values in the parameter are in microseconds. For example, 1 second is equal to 100000 microseconds.
Prerequisites
- You must have root permission on your system.
Procedure
Set the required value temporarily by using one of the
sysctlcommands.To use the
sched_deadline_period_max_usparameter, run the following command:# sysctl -w kernel.sched_deadline_period_max_us=2000000To use the
sched_deadline_period_min_usparameter, run the following command:# sysctl -w kernel.sched_deadline_period_min_us=100
Set the values persistently.
For
max_us, edit/etc/sysctl.confand add the following line:kernel.sched_deadline_period_max_us = 2000000
For
min_us, edit/etc/sysctl.confand add the following line::kernel.sched_deadline_period_min_us = 100
Apply the changes:
# sysctl -p
Verification
Verify the custom values of
max_us:$ cat /proc/sys/kernel/sched_deadline_period_max_us 2000000Verify the custom values of
min_us:$ cat /proc/sys/kernel/sched_deadline_period_min_us 100
