LinuxVI · ProcessesPriorities
Nice, renice, and CPU scheduling priorities
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
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.
$ nice -n 5 ./batch-job.sh; nice -n -10 ./critical-monitor.shIllustrative output
$ renice -n -5 -p 1234; renice -n 10 -u aliceIllustrative output
$ top -n 1 -b | head -10top - 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.
$ chrt -f -p 50 1234; chrt -r -p 10 1234Illustrative output
CPU affinity
$ taskset -cp 0-3 1234; taskset -cp 0 1234pid 1234's current affinity mask: 0-3
pid 1234's current affinity mask: 0Illustrative output
$ taskset -c 0-3 nice -n -5 ./process.shIllustrative 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 (
CPUQuotain 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
| Practice | Why |
|---|---|
| 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
Q1. What is the valid range of nice values on Linux?
Q2. A single runaway SCHED_FIFO task can lock up an entire host.
Q3. Which of the following are correct scheduling practices? Select all that apply.
Passing score: 75%. Answers are checked in this browser.