Chapter 3. Realtime-Specific Tuning
Once you have completed the optimization in Chapter 2, General System Tuning you are ready to start Red Hat Enterprise Linux for Real Time specific tuning. You must have the Red Hat Enterprise Linux for Real Time kernel installed for these procedures.
Important
Do not attempt to use the tools in this section without first having completed Chapter 2, General System Tuning. You will not see a performance improvement.
When are you ready to begin Red Hat Enterprise Linux for Real Time tuning, perform these steps first, as they will provide the greatest benefit:
When you are ready to start some fine-tuning on your system, then try the other sections in this chapter:
This chapter also includes information on performance monitoring tools:
When you have completed all the tuning suggestions in this chapter, move on to Chapter 4, Application Tuning and Deployment
3.1. Setting Scheduler Priorities
The Red Hat Enterprise Linux for Real Time kernel allows fine-grained control of scheduler priorities. It also allows application-level programs to be scheduled at a higher priority than kernel threads.
Warning
Setting scheduler priorities can carry consequences. It is possible that it will cause the system to become unresponsive and other unpredictable behavior if crucial kernel processes are prevented from running as needed. Ultimately the correct settings are workload-dependent.
Priorities are defined in groups, with some groups dedicated to certain kernel functions:
Table 3.1. Priority Map
Priority | Threads | Description |
---|---|---|
1 | Low priority kernel threads | Priority 1 is usually reserved for those tasks that need to be just above SCHED_OTHER . |
2 - 49 | Available for use | The range used for typical application priorities |
50 | Default hard-IRQ value | |
51 - 98 | High priority threads | Use this range for threads that execute periodically and must have quick response times. Do not use this range for CPU-bound threads as you will starve interrupts. |
99 | Watchdogs and migration | System threads that must run at the highest priority |
Procedure 3.1. Using systemd
to Set Priorities
- Priorities are set using a series of levels, ranging from
0
(lowest priority) to99
(highest priority). Thesystemd
service manager can be used to change the default priorities of threads following kernel boot.To view scheduling priorities of running threads, use the tuna utility:~]#
tuna --show_threads
thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 2 OTHER 0 0xfff 451 3 kthreadd 3 FIFO 1 0 46395 2 ksoftirqd/0 5 OTHER 0 0 11 1 kworker/0:0H 7 FIFO 99 0 9 1 posixcputmr/0 ...[output truncated]...
3.1.1. Changing the priority of service during boot process
systemd
makes it possible to set up real-time priority for services launched during the boot process.
The unit configuration directives are used to change the priority of a service during boot process. The boot process priority change is done by using the following directives in the service section:
- CPUSchedulingPolicy=
- Sets the CPU scheduling policy for executed processes. Takes one of the scheduling classes available on linux:
- other
- batch
- idle
- fifo
- rr
- CPUSchedulingPriority=
- Sets the CPU scheduling priority for executed processes. The available priority range depends on the selected CPU scheduling policy. For real-time scheduling policies, an integer between 1 (lowest priority) and 99 (highest priority) can be used.
Example 3.1. Changing the priority of the mcelog service
The following example uses the
mcelog
service. To change the priority of the mcelog
service:
- Create a supplementary
mcelog
service configuration directory file at/etc/systemd/system/mcelog.system.d/priority.conf
as follows:# cat <<-EOF > /etc/systemd/system/mcelog.system.d/priority.conf
- Insert the following:
[SERVICE] CPUSchedulingPolicy=fifo CPUSchedulingPriority=20 EOF
- Reload the
systemd
scripts configuration:# systemctl daemon-reload
- Restart the
mcelog
service:# systemctl restart mcelog
- Display the
mcelog
priority set bysystemd
issue the following:$ tuna -t mcelog -P
The output of this command should now be similar to the following:thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 826 FIFO 20 0,1,2,3 13 0 mcelog
For more information about changing the
systemd
unit configuration directives refer to the Modifying Existing Unit Files chapter of the System Administrator's Guide.
3.1.2. Configuring the CPU usage of a service
systemd
makes it possible to specify which CPUs services are allowed to run on.
To do so, systemd uses the CPUAffinity= unit configuration directive.
Example 3.2. Configuring the CPU usage of the mcelog service
The following example restricts the
mcelog
service to run on CPUs 0 and 1:
- Create a supplementary
mcelog
service configuration directory file at/etc/systemd/system/mcelog.system.d/affinity.conf
as follows:# cat <<-EOF > /etc/systemd/system/mcelog.system.d/affinity.conf
- Insert the following:
[SERVICE] CPUAffinity=0,1 EOF
- Reload the
systemd
scripts configuration:# systemctl daemon-reload
- Restart the
mcelog
service:# systemctl restart mcelog
- Display which CPUs the
mcelog
service is restricted to:$ tuna -t mcelog -P
The output of this command should now be similar to the following:thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 12954 FIFO 20 0,1 2 1 mcelog
For more information about changing the
systemd
unit configuration directives, refer to the Modifying Existing Unit Files chapter of the System Administrator's Guide.