|Index|Shielding Linux Resources on SUSE Linux Enterprise Server
SUSE Linux Enterprise Server 16.1

Shielding Linux Resources on SUSE Linux Enterprise Server

Publication Date: 05 Nov 2026

CPU shielding in SUSE Linux Enterprise Server isolates specific processors on a multi-core system exclusively for high-priority and real-time workloads. By using systemd and the cgroups v2 cpuset controller, administrators can isolate designated processors from standard system services and non-critical kernel threads. This isolation ensures deterministic execution times and eliminates latency spikes caused by resource contention, which is essential for real-time applications.

Prerequisites

  • A multi-core system

1 What is CPU shielding?

 

CPU shielding is the practice of reserving specific CPUs on a multi-core system strictly for high-priority or real-time tasks. It works by isolating these designated CPUs from general user processes, standard system services, and non-critical kernel threads.

In a standard, unshielded Linux environment, the kernel's scheduler freely migrates processes across all available CPUs to balance the load. While this is efficient for general computing, it introduces unpredictability. If a standard background service or a kernel interrupt is scheduled on the same CPU as a critical real-time task, it forces the real-time task to wait. This waiting period introduces latency.

By implementing a CPU shield, you guarantee that only the specific workloads you authorize are allowed to execute on the shielded processors. This ensures deterministic execution times and eliminates latency spikes caused by resource contention, which is essential for real-time applications.

Important
Important: The legacy cset

The legacy cset command-line utility relies on the older cgroups v1 hierarchy and is no longer supported in SLES 16.1. All CPU isolation and thread assignment must be managed using systemd configuration files and commands.

1.1 How does CPU shielding work?

 

In SLES 16.1, systemd serves as the central manager for all system resources, including CPU allocation. It interacts directly with the kernel's cgroups v2 cpuset controller to assign specific CPUs to services and processes.

systemd natively supports the cpuset controller under the unified cgroups v2 hierarchy. Resource distribution in cgroups v2 follows a top-down model across the system hierarchy. systemd automatically creates top-level units, including init.scope, system.slice, user.slice, and machine.slice. To establish a shield, you configure AllowedCPUs on these default units to restrict them to non-shielded CPUs. You then create a custom workload slice assigned to the remaining shielded CPUs. systemd manages these resource boundaries directly without external utilities.

2 Setting up a CPU shield

 

The general idea is to have one cpuset for the main sensitive workload and a complementary cpuset for the supporting tasks. Resources are distributed top-down, so we must consider all top-level cgroups on the system to ensure proper allocation for the main workload. By default, systemd creates the following units: init.scope, system.slice, user.slice and machine.slice. You can establish system-wide CPU shields using standard slice drop-in files or dynamic systemctl commands.

2.1 Setting up systemd CPU shield using drop-in files

 

This approach isolates standard system processes into non-shielded CPUs while creating a dedicated slice for real-time applications.

  1. Create drop-in configuration files for init.scope, system.slice, user.slice, and machine.slice (for example, 40-shielding.conf) specifying the unshielded CPU cores.

    • For the init.scope, run:

      > sudo cat /etc/systemd/system/init.scope.d/40-shielding.conf
[Scope]
AllowedCPUs=0-1

    • For the system.slice, run:

      > sudo cat /etc/systemd/system/system.slice.d/40-shielding.conf
[Slice]
AllowedCPUs=0-1

    • For the user.slice, run:

      > sudo cat /etc/systemd/system/user.slice.d/40-shielding.conf
[Slice]
AllowedCPUs=0-1

    • For the machine.slice, run:

      > sudo cat /etc/systemd/system/machine.slice.d/40-shielding.conf
[Slice]
AllowedCPUs=0-1

  2. Create a custom workload slice file at /etc/systemd/system/workload.slice to assign isolated cores exclusively to real-time tasks. 

    > sudo cat /etc/systemd/system/workload.slice
[Slice]
AllowedCPUs=2-15

  3. Reload the systemd manager configuration to apply the new unit files. 

    > sudo systemctl daemon-reload

    The command output confirms the shielded range assigned to the slice aka 2-15.

  4. Verify the CPU assignment by checking the cpuset.cpus file in the cgroup filesystem. 

    > sudo cat /sys/fs/cgroup/workload.slice/cpuset.cpus
2-15

2.2 Setting up systemd CPU shield using systemctl

 

Standard slices can also be restricted on the fly using systemctl set-property. For example, to restrict the operating system to core 0‐2:

  • For the init.scope, run:

    > sudo systemctl set-property init.scope AllowedCPUs=0-2

  • For the system.slice, run:

    > sudo systemctl set-property system.slice AllowedCPUs=0-2

  • For the user.slice, run:

    > sudo systemctl set-property user.slice AllowedCPUs=0-2

3 Managing jobs and services within a shield

 

This section explains how to manage jobs and services within the shielded environment, showing you how to assign both persistent systemd services and ad-hoc tasks to the dedicated workload.slice. Additionally, it covers how to safely unshield processes and return them to standard system CPUs when dedicated resources are no longer required.

3.1 Assigning services and tasks to the shielded slice

 

To execute workloads within the CPU shield, assign systemd service units or transient scopes to workload.slice.

  1. Create a drop-in configuration file for your service to assign it to workload.slice. 

    > sudo cat /etc/systemd/system/SENSITIVE.service.d/40-shielding.conf
[Service]
Slice=workload.slice

  2. Restart the service unit to apply the new slice configuration. 

    > sudo systemctl restart SENSITIVE.service

  3. To run an ad-hoc command inside the shield, execute it within a transient scope using systemd-run. 

    > sudo systemd-run --scope --uid=tux -p Slice=workload.slice command arg1

3.2 Unshielding processes

 

To remove a process from a CPU shield, reassign its AllowedCPUs setting back to standard system CPUs. For transient applications created with systemd-run, stopping the transient unit unshields the process: 

> sudo systemctl stop RT-APPLICATION

4 Troubleshooting CPU shielding issues

 

When setting up or using a shield, several questions or issues may arise. The following list addresses the most common questions.

CPU shielding troubleshooting

1. How do I verify that the CPU shield is active in cgroups v2?

Check the cpuset.cpus file for workload.slice in the sysfs filesystem at /sys/fs/cgroup/workload.slice/cpuset.cpus. The command output must list only the CPUs assigned to the shield.

2. How do I check whether a service is running inside the shielded slice?

Run systemctl status SENSITIVE.service to inspect the active slice and cgroup path. Alternatively, run systemctl show SENSITIVE.service -p Slice,AllowedCPUs to confirm configuration properties.

3. How do I troubleshoot service failures or incorrect CPU assignments?

Use journalctl -u SENSITIVE.service to view unit log messages. Verify that drop-in files exist in the correct configuration directories and run systemctl daemon-reload after making changes.