Configuring cgroups v2 on the Desktop to Prevent Web Browsers From Starving Critical Terminal Compilations

Ključne točke

1. Enable cgroups v2. Most modern distributions use it by default; verify with mount | grep cgroup2.
2. Create a browser slice. Use systemd-run or a transient unit to place the browser in a capped cgroup.
3. Set CPU and memory limits. cpu.max and memory.max enforce hard ceilings that the kernel honors.
4. Protect terminal sessions. Give the shell and build processes a higher cpu.weight so they preempt the browser.
5. Use memory.high for graceful pressure. It triggers reclaim before the hard limit, avoiding sudden kills.
6. Monitor with systemd-cgtop. Watch per-cgroup usage to confirm limits are effective.
7. Persist via unit files. Drop-in units for the browser keep the configuration across reboots.
8. Test under load. Run a heavy browser workload alongside a compilation and measure completion time.

Architecture

cgroups v2 organizes processes into a hierarchy where each node carries resource controllers. The browser lives in a capped leaf, terminal sessions live in a protected leaf, and the root distributes leftover capacity. The kernel enforces limits atomically, so no userspace cooperation is required.

Production configuration

systemd-run --user --scope --unit=browser-capped \
  -p CPUQuota=200% \
  -p MemoryMax=4G \
  -p MemoryHigh=3G \
  firefox

# verify
systemd-cgtop --depth=2

# ~/.config/systemd/user/browser-capped.service
[Unit]
Description=Capped browser session

[Service]
ExecStart=/usr/bin/firefox
CPUQuota=200%
MemoryMax=4G
MemoryHigh=3G
Slice=app-browser.slice

[Install]
WantedBy=default.target

# Raise weight for the terminal slice
systemctl --user set-property app-terminal.slice CPUWeight=200
systemctl --user set-property app-terminal.slice MemoryLow=1G

# check weights
cat /sys/fs/cgroup/user.slice/user-1000.slice/app-terminal.slice/cpu.weight

Edge cases from production

• Browsers spawn many child processes; the cgroup must cover the whole subtree, which systemd scopes handle automatically.
• GPU-accelerated rendering bypasses CPU limits for graphics work; cap GPU memory separately if needed.
• MemoryMax kills the browser abruptly; use MemoryHigh first and only escalate if pressure persists.
• Flatpak apps run in their own cgroup namespace; limits must be applied at the flatpak level.

Često postavljana pitanja