Tune Linux CPU Utilisation Hints with uclampset

uclampset tunes a task's CPU utilisation clamp, so the scheduler treats it as busier or lazier than it really is. You will finish with a repeatable way to inspect that clamp, apply a temporary minimum and maximum, and restore the task to the system default. The examples use the uclampset binary from util-linux 2.42.4 on this machine. Its installed manpage is from util-linux 2.39.3, so the command-line details below are checked against both the local documentation and the installed program.

Allow about ten minutes. You need a Linux system with util-linux installed and a process you are allowed to inspect. The command changes scheduler attributes, not CPU frequency directly. Its effect also depends on the kernel and on the schedutil CPU-frequency governor.

1. Check the command and the value range

Start by confirming which executable your shell will run:

$ command -v uclampset
/home/linuxbrew/.linuxbrew/bin/uclampset
$ uclampset --version
uclampset from util-linux 2.42.4

Utilisation values run from 0 to 1024. A higher minimum asks the scheduler to treat a task as if it has at least that utilisation. A maximum below 1024 caps the utilisation that the task can present to the scheduler. These are scheduling hints, not promises about performance or a direct request for a particular clock speed.

Checkpoint: run uclampset --help and confirm that your build provides -m, -M, -p, -s and -v. Use the short forms shown here where the local help is the authority.

2. Inspect a process without changing it

Every process has a PID. The shell's current PID is available as $$, so this read-only command is safe to try:

$ uclampset --pid $$ --verbose
bash (4124838) util_clamp: min: 0 max: 1024

Your PID and process name will differ. The useful part is the reported pair. On this machine, 0 and 1024 are the ordinary per-task limits. The -p option selects an existing PID; without it, the normal mode launches a new command with the requested attributes.

Reading scheduling information does not require elevated privilege according to the manpage. If the process belongs to another user or the kernel rejects the request, preserve the command's error and exit status rather than guessing what its clamp is.

3. Apply a reversible clamp to a test process

Use a process that you can safely stop. This example starts sleep, sets a minimum of 300 and a maximum of 700, then reads the result:

$ sleep 60 &
$ pid=$!
$ uclampset -p "$pid" -m 300 -M 700
$ uclampset -p "$pid" -v
sleep (4125371) util_clamp: min: 300 max: 700

The shell variable pid avoids copying a possibly stale number. A minimum and maximum must describe a sensible range, and both values must be within 0 to 1024. The exact scheduling outcome still depends on the running kernel and hardware.

Checkpoint: Confirm that the reported values are the ones you requested before applying an example to a real service. If the command fails, inspect its status with printf '%s\n' "$?" immediately afterwards.

4. Undo the per-process change

Do not leave a test clamp behind. The special value -1 resets an attribute to the system default:

$ uclampset -p "$pid" -m -1 -M -1
$ uclampset -p "$pid" -v
sleep (4125371) util_clamp: min: 0 max: 1024
$ kill "$pid"
$ wait "$pid" 2>/dev/null || true

Resetting both attributes is the recovery step for the example. If you are changing a long-running process, record its original output first and restore those values explicitly instead of assuming they were 0 and 1024.

5. Run a command with a clamp from the start

The default mode starts a command rather than operating on an existing PID. Put the clamp options before the command and its arguments:

$ uclampset -m 256 -M 768 /path/to/worker --one-job

Replace /path/to/worker and its arguments with a real command. The new process inherits the requested attributes for its launch. If you need to verify a command that stays running, inspect its PID from another shell with uclampset -p PID -v. Do not use an example path as though it were an installed program.

6. Treat privileges and system scope as boundaries

The manpage says that changing a process's scheduling attributes requires CAP_SYS_NICE. A normal user may therefore be able to read a task but not change it. Prefer running the task as the intended service user and granting only the capability or service configuration it genuinely needs. Avoid reaching for sudo until the error shows that privilege is the actual problem.

The -a option operates on all threads for a given PID. That can be useful for a multithreaded program, but it changes more tasks than the single-process example. Confirm the PID and the scope before using it.

Do not experiment with -s on a production host. It changes the system-wide allowed range. The manpage documents a system query such as:

$ uclampset -s -v
System util_clamp: min: 1024 max: 1024

That query is read-only. Supplying -m or -M with -s changes the ceiling available to tasks across the system and can reduce performance for unrelated workloads. Before any planned change, capture the current values. To undo a deliberate system-wide change, set the recorded values back, with the required scheduling privilege, and verify with uclampset -s -v. If you do not know the original values, stop and investigate rather than guessing.

7. Avoid the common interpretation traps

Done means