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) to 99 (highest priority). The systemd 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:
  1. 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
  2. Insert the following: 
    [SERVICE]
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=20
EOF
  3. Reload the systemd scripts configuration: 
    # systemctl daemon-reload
  4. Restart the mcelog service: 
    # systemctl restart mcelog
  5. Display the mcelog priority set by systemd 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:
  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
  2. Insert the following: 
    [SERVICE]
CPUAffinity=0,1
EOF
  3. Reload the systemd scripts configuration: 
    # systemctl daemon-reload
  4. Restart the mcelog service: 
    # systemctl restart mcelog
  5. 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.