Skip to main content
RunBook Academy

LinuxVI · ProcessesPriorities

Nice, renice, and CPU scheduling priorities

Foundation⏱ ~10 minbashnicerenicetoptaskset

What you'll learn

  • Distinguish nice value from real-time priority
  • Use nice and renice to adjust scheduling priority
  • Configure CPU affinity with taskset
  • Recognise the limits of nice — when CFS will not help

Prerequisites

Verified against Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL 9.x · Rocky Linux 9.x · AlmaLinux 9.x · Linux kernel 6.1 LTS / 6.6 LTS · systemd 255+ · OpenSSH 8.7p1 (RHEL 9) / 9.6p1 (Ubuntu 24.04) · nftables 1.0.x · chrony 4.x · Pacemaker 2.1.x · Corosync 3.1.x · 2026-08-09

Not yet marked complete on this device.

Linux has two scheduling-priority concepts that confuse newcomers. Nice value is the polite request: “give me less CPU if something more important needs it”. Real-time priority is the strict demand: “give me CPU before anything except equal or higher real-time tasks”. The two are different mechanisms with different use cases.

Nice value

The nice value is an integer from -20 (highest priority, most CPU) to +19 (lowest priority, least CPU). The default is 0.

Configuration changenice
$ nice -n 5 ./batch-job.sh; nice -n -10 ./critical-monitor.sh

Illustrative output

Configuration changerenice
$ renice -n -5 -p 1234; renice -n 10 -u alice

Illustrative output

Read-only / Safetop with NI
$ top -n 1 -b | head -10
top - 12:00:00 up 30 days,  3:45,  1 user,  load average: 4.20, 3.10, 2.50
Tasks: 234 total,   3 running
%Cpu(s): 12.5 us,  0.0 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  16000.0 total,   1234.5 free,   8901.2 used,   5864.3 buff/cache

PID USER   PR  NI   VIRT   RES   SHR  S  %CPU  %MEM     TIME+  COMMAND
12345 root   20   0  1234m  456m  123m  R  95.0   1.1   0:42.15  nginx
12346 www-d  25   5  1234m  456m  123m  S   2.0   1.1   0:01.20  nginx
...

Illustrative output

Real-time priority

Linux has two real-time scheduling classes: SCHED_FIFO (first-in, first-out) and SCHED_RR (round-robin). Real-time tasks have priority 1-99; higher is more urgent.

Configuration changechrt
$ chrt -f -p 50 1234; chrt -r -p 10 1234

Illustrative output

CPU affinity

Configuration changetaskset
$ taskset -cp 0-3 1234; taskset -cp 0 1234
pid 1234's current affinity mask: 0-3
pid 1234's current affinity mask: 0

Illustrative output

Configuration changetaskset + nice
$ taskset -c 0-3 nice -n -5 ./process.sh

Illustrative output

When nice does not help

nice is a polite request to the scheduler. It does not:

  • Grant more CPU than is available.
  • Bypass cgroup limits (CPUQuota in systemd unit files).
  • Override real-time priorities.
  • Reduce I/O wait time (the process is still waiting for the disk).

If a process is CPU-bound and the host has spare CPU, lowering the nice value (raising priority) gives it more CPU. If the host is saturated, lowering the nice value of one process starves others — the overall throughput is bounded.

Production discipline

PracticeWhy
Use nice for batch jobs.Nightly ETL, backups, log rotation — they should yield to interactive load.
Never use real-time priority for production daemons.A runaway real-time task can lock the host.
Use CPU affinity when NUMA locality matters.On large hosts, memory access across NUMA nodes is 30-50% slower.
Never disable the CFS bandwidth control.CPUQuota is the right way to throttle a service.

Knowledge check

Knowledge check · 3 questions

  1. Q1. What is the valid range of nice values on Linux?

  2. Q2. A single runaway SCHED_FIFO task can lock up an entire host.

  3. Q3. Which of the following are correct scheduling practices? Select all that apply.

Passing score: 75%. Answers are checked in this browser.