Nice is the per-process scheduling hint in Linux that tells the kernel how generously to share CPU time with a process, and it is also the name of the command that starts a program with a chosen value. The nice value ranges from -20 to 19, with 0 as the default: a higher value makes a process “nicer” to others by yielding CPU time, while a lower value makes it more demanding.
In Linux processes, nice applies to the normal scheduling classes only. It shapes how the CPU is divided among runnable tasks that compete for the same cores, but it does not reserve CPU time, it does not affect memory, and it has no effect on an idle system where every task already gets the CPU it asks for.
How the nice value influences the scheduler
The Linux scheduler translates each nice value into a load weight. Under the Completely Fair Scheduler, and under the EEVDF scheduler that replaced it in kernel 6.6, a task with nice 0 has a weight of 1024, and each step of nice changes the weight by roughly a factor of 1.25. This means one step of nice shifts about 10 percent of CPU time between two competing tasks.
The table shows the weights for selected nice values and the approximate CPU share when such a task competes with one nice-0 task on a single core.
| Nice value | Kernel weight | Approximate CPU share |
|---|---|---|
| -20 | 88761 | About 99 percent |
| -10 | 9548 | About 90 percent |
| -5 | 3121 | About 75 percent |
| 0 | 1024 | 50 percent |
| 5 | 335 | About 25 percent |
| 10 | 110 | About 10 percent |
| 19 | 15 | About 1.5 percent |
Because the effect is relative rather than absolute, the same nice value produces different results depending on what else runs. A nice-19 batch job on an otherwise idle machine still receives nearly the full CPU, and it only yields when other runnable tasks compete for the same core.
The nice and renice commands
The nice command starts a new program with an adjusted value, while renice changes the value of a process that is already running. Both operate on the same kernel attribute, which the ps -o ni and top columns display as NI.
| Command | Purpose | Example |
|---|---|---|
| nice | Start a command with an offset | nice -n 10 tar czf backup.tgz /srv |
| renice | Change a running process | renice -n 5 -p 4321 |
| renice -u | Change all processes of a user | renice -n 10 -u builder |
| ps / top | Display the current value | ps -o pid,ni,cmd -p 4321 |
| systemd Nice= | Set the value for a service unit | Nice=10 in the [Service] section |
Without the -n option, nice adds an increment of 10. Values outside the range are clamped, so nice -n 50 simply results in nice 19. Child processes inherit the nice value of their parent, so starting a shell with nice 10 makes every command run from it equally polite.
Permissions and limits on nice values
Any user may raise the nice value of their own processes, making them less demanding. Lowering the value below its current level, and therefore claiming more CPU, requires the CAP_SYS_NICE capability, which normally means root. This asymmetry prevents ordinary users from starving other users on a shared system.
The resource limit RLIMIT_NICE relaxes this rule in a controlled way. Configured through /etc/security/limits.conf with the nice item, or through LimitNICE= in a systemd unit, it lets a specific user or service lower its value down to a defined floor, which is common for audio and media workloads.
Nice compared with related scheduling controls
Nice is only one of several tools that shape CPU usage, and it is the weakest and simplest of them. Process priority as a broader concept, CPU affinity and cgroups solve different problems, and choosing the right one avoids frustration.
| Control | What it changes | Scope | Strength |
|---|---|---|---|
| Nice | Relative weight in the fair scheduler | One process or thread | Soft, only under contention |
| Real-time priority | Policy SCHED_FIFO or SCHED_RR, levels 1-99 | One process or thread | Strict, preempts all normal tasks |
| CPU affinity | Which cores a task may run on | One process or thread | Hard placement, no share control |
| Cgroup cpu.weight | Relative weight of a group of tasks | A whole service or container | Soft, applies across groups |
| Cgroup cpu.max | Absolute quota per period | A whole service or container | Hard ceiling even on idle CPU |
An important interaction is the autogroup feature. On many desktop distributions the kernel groups tasks by session, and nice values then compete only within the same session. A nice-19 job started in one terminal can therefore still receive half of the CPU against a nice-0 job in another session, which surprises administrators who expect a global effect.
When to use nice and when not to
Nice works best for long-running, CPU-bound background work that should not disturb interactive use or latency-sensitive services. It does not help when the bottleneck is disk or memory, because the I/O scheduler and the memory manager largely ignore it.
| Situation | Recommended control | Reason |
|---|---|---|
| Nightly compression or backups | nice 10-19 plus ionice | Yields CPU and disk to live services |
| Compiling on a developer workstation | nice 10 | Keeps the desktop responsive |
| Limiting a container to two cores | cgroup cpu.max | Nice cannot set an absolute cap |
| Low-latency audio processing | Real-time priority | Nice cannot guarantee deadlines |
| Database competing with batch jobs | cgroup cpu.weight per service | Applies to all threads of each service |
- Pair nice with
ionice -c3when a job is heavy on disk as well as CPU. - Do not lower nice values of daemons to fix slowness without measuring; it often hides a capacity problem.
- Remember that nice is per thread in Linux, so renice on one thread ID does not change sibling threads.
- Verify the effect under real contention with top or htop rather than on an idle test machine.
Put simply
Nice is a politeness setting for programs. When several programs want the processor at the same moment, a polite program with a high nice value steps aside and lets the others go first, while a pushy one with a low value claims a bigger turn.
If nobody else is waiting, even the most polite program gets the whole processor. Nice only matters when there is competition, and only an administrator may make a program pushier than it was.
In practice
A web hosting server with eight cores runs customer websites during the day and a nightly job that compresses about 200 GB of log files. When the job ran at the default nice 0, page response times rose sharply during the compression window, because the job occupied several cores at full load.
The administrator changes the cron entry to nice -n 19 ionice -c3 /usr/local/bin/compress-logs. The job now uses the CPU only when web requests leave cores free, and it still finishes before morning because the server is lightly loaded at night. Response times during the window return to their normal level, and the change costs nothing beyond a slightly longer job duration.