Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 22. Configuring CPU Affinity and NUMA policies using systemd

The CPU management, memory management, and I/O bandwidth options deal with partitioning available resources.

22.1. Configuring CPU affinity using systemd

CPU affinity settings help you restrict the access of a particular process to some CPUs. Effectively, the CPU scheduler never schedules the process to run on the CPU that is not in the affinity mask of the process.

The default CPU affinity mask applies to all services managed by systemd.

To configure CPU affinity mask for a particular systemd service, systemd provides CPUAffinity= both as a unit file option and a manager configuration option in the /etc/systemd/system.conf file.

The CPUAffinity= unit file option sets a list of CPUs or CPU ranges that are merged and used as the affinity mask. The CPUAffinity option in the /etc/systemd/system.conf file defines an affinity mask for the process identification number (PID) 1 and all processes forked off of PID1. You can then override the CPUAffinity on a per-service basis.

Note

After configuring CPU affinity mask for a particular systemd service, you must restart the system to apply the changes.

Procedure

To set CPU affinity mask for a particualr systemd service using the CPUAffinity unit file option:

  1. Check the values of the CPUAffinity unit file option in the service of your choice:

    $ systemctl show --property <CPU affinity configuration option> <service name>
  2. As a root, set the required value of the CPUAffinity unit file option for the CPU ranges used as the affinity mask:

    # systemctl set-property <service name> CPUAffinity=<value>
  3. Restart the service to apply the changes.

    # systemctl restart <service name>

To set CPU affinity mask for a particular systemd service using the manager configuration option:

  1. Edit the /etc/systemd/system.conf file:

    # vi /etc/systemd/system.conf
  2. Search for the CPUAffinity= option and set the CPU numbers
  3. Save the edited file and restart the server to apply the changes.

22.2. Configuring NUMA using systemd

Non-uniform memory access (NUMA) is a computer memory subsystem design, in which the memory access time depends on the memory location relative to the processor. Memory close to the CPU has lower latency (local memory) than memory that is local for a different CPU or is shared between a set of CPUs.

In terms of the Linux kernel, NUMA policy governs where (for example, on which NUMA nodes) the kernel allocates physical memory pages for the process.

To configure NUMA, systemd provides the unit file option for NUMAPolicy and NUMAMask, and the manager configuration option in the /etc/systemd/system.conf file.

Procedure

To set the NUMA memory policy through the NUMAPolicy unit file option:

  1. Check the values of the NUMAPolicy unit file option in the service of your choice:

    $ systemctl show --property <NUMA policy configuration option> <service name>
  2. As a root, set the required policy type of the NUMAPolicy unit file option:

    # systemctl set-property <service name> NUMAPolicy=<value>
  3. Restart the service to apply the changes.

    # systemctl restart <service name>

To set the NUMAPolicy through the manager configuration option:

  1. Edit the /etc/systemd/system.conf file:

    # vi /etc/systemd/system.conf
  2. Search for the NUMAPolicy option and set the policy type.
  3. Save the edited file and restart the server to apply the changes.

22.3. NUMA policy configuration options for systemd

systemd provides the following options to configure the NUMA policy:

NUMAPolicy

Controls the NUMA memory policy of the executed processes. The following policy types are possible:

  • default
  • preferred
  • bind
  • interleave
  • local
NUMAMask

Controls the NUMA node list which is associated with the selected NUMA policy.

Note that the NUMAMask option is not required to be specified for the following policies:

  • default
  • local

For the preferred policy, the list specifies only a single NUMA node.

Additional resources