Overview

StorPool uses Linux control groups to manage CPU and memory resources for its services. This page describes the Control Groups v2 configuration model used for StorPool resource management.

The v2 configuration keeps the same resource-management decisions as the previous Control Groups v1 setup. The main change is how the limits and CPU assignments are represented and applied, because Control Groups v2 uses a single unified hierarchy instead of separate controller hierarchies.

Default Control Groups v2 platforms

StorPool could use Control Groups v2 by default from the following operating systems:

  • Ubuntu 24.04

  • Debian 12

  • Proxmox VE 8

  • AlmaLinux 9

  • Rocky Linux 9

  • Oracle Linux 9

This default applies regardless of the kernel version.

Existing production nodes running these operating systems may still be using Control Groups v1. They should be migrated to Control Groups v2 at the first convenient maintenance opportunity, usually during the next scheduled kernel upgrade.

Since Linux kernel 6.11, the memory controller in the cgroups v1 hierarchy can no longer limit memory usage, so using cgroups v2 is the only option for kernel 6.11 and newer.

Unified hierarchy

Control Groups v2 uses a unified hierarchy. Unlike Control Groups v1, it does not have separate group trees for each controller, such as separate cpuset and memory hierarchies.

Instead, each group in the tree may have multiple controllers enabled under it. StorPool therefore uses a single slice hierarchy where CPU and memory configuration are applied to the relevant slices and services.

The expected hierarchy is:

system.slice
user.slice
machine.slice                         # optional; name is configurable
storpool.slice
 storpool-alloc.slice                  # optional
 storpool-common.slice
  storpool-common-rdma.slice

The machine.slice name is configurable and may not be present on every node.

Controller requirements

The following controllers should be enabled for the relevant StorPool slices:

  • cpuset

  • memory

The system.slice, user.slice, machine.slice when used, and storpool.slice are created by systemd from their .slice unit files.

The storpool_cg tool is responsible for configuring the appropriate CPU sets and memory limits for StorPool slices and services.

Cgroups management

The configuration is applied through systemd unit properties, such as slice placement, allowed CPUs and memory limits. Systemd then creates and manages each service’s cgroup according to that configuration, ensuring the configured resource constraints are applied when the service starts and remain persistent across reboots.

Examples of how systemd.resource-control is configured:

systemctl set-property storpool_beacon.service AllowedCPUs=1
systemctl set-property storpool.slice MemoryMax=21G

This creates a persistent systemd override for the unit. The configuration survives reboot and is applied by systemd when the service is started.

Memory configuration

Control Groups v2 provides the following memory controls:

  • memory.min

  • memory.low

  • memory.high

  • memory.max

StorPool configures them as follows:

memory.min  = default
memory.low  = default
memory.high = default
memory.max  = <current Control Groups v1 memory limit>

Swap and zswap controls are separate in Control Groups v2. StorPool does not need swap for its service cgroups, so swap usage should be disabled:

memory.swap.max = 0

If zswap is managed explicitly on the target platform, it should also be set to zero for the relevant cgroups.

Configuration ownership

The storpool_cg tool is responsible for:

  • detecting when Control Groups v2 should be used

  • creating or updating the required StorPool slice configuration

  • enabling the required controllers

  • applying CPU pinning through systemd properties

  • applying memory limits through the Control Groups v2 memory controller

Systemd is responsible for:

  • creating slices from their .slice files

  • creating service groups

  • applying persistent service property overrides

  • starting services in their configured slices