Renice Value Calculator
Calculate the renice adjustment needed to shift a running process's CPU scheduling priority.
Inputs
Impact
Lower priority — weight drops from 1024 to 110 (89.3% less relative CPU share under contention); vruntime will now accrue 9.31× faster, so it will be scheduled less often when other tasks compete.
Relative CPU Share Change
-89.3%
Current Scheduling Weight
1,024
New Scheduling Weight
110
Requires root/CAP_SYS_NICE?
false
Equivalent renice Command
renice -n 10 -p <pid>
Step by step
Values used
Current Nice Value = 0; New Nice Value (after renice) = 10
Weight change and CPU share impact
weight_change_ratio = new_weight / current_weight; cpu_share_change% = (weight_change_ratio − 1) × 100
Impact
= Lower priority — weight drops from 1024 to 110 (89.3% less relative CPU share under contention); vruntime will now accrue 9.31× faster, so it will be scheduled less often when other tasks compete.
Relative CPU Share Change
= -89.3
Current Scheduling Weight
= 1,024
New Scheduling Weight
= 110
Requires root/CAP_SYS_NICE?
= No
Equivalent renice Command
= renice -n 10 -p <pid>
How it works
renice changes a running process's nice value without restarting it, immediately updating its CFS scheduling weight (from the same sched_prio_to_weight table used at process start) and therefore its future vruntime accrual rate and relative CPU share whenever it competes with other runnable tasks. Increasing the nice value (lower priority) is always allowed by the process owner, but decreasing it (raising priority, moving toward -20) requires root privileges or the CAP_SYS_NICE capability, since unprivileged users could otherwise starve other users' processes of CPU time by granting themselves ever-higher priority.
Formula
Weight change and CPU share impact
weight_change_ratio = new_weight / current_weight; cpu_share_change% = (weight_change_ratio − 1) × 100
- w_{new}
- weight at the new nice value
- w_{cur}
- weight at the current nice value
Frequently Asked Questions
Does renice affect a process immediately, or only for its next fork?
Immediately — renice changes the live scheduling weight of an already-running process (and, with `renice -p`, only that specific PID unless you also target its process group or all processes for a user), taking effect on the very next scheduling decision without needing a restart.
Why can't I renice my own process to a lower (higher-priority) nice value?
Unprivileged users are restricted from lowering nice values (raising priority) via the CAP_SYS_NICE capability check, specifically to prevent users from self-granting priority that would let their processes starve other users' or the system's processes of CPU time. Root (or a process explicitly granted CAP_SYS_NICE) has no such restriction.
Does renicing a multi-threaded process affect all its threads?
By default, `renice -p <pid>` targets only the main thread's PID; to affect all threads of a process you generally need to renice each thread ID individually (visible via `ps -eLf` or /proc/<pid>/task/), since each thread has its own nice value/weight in the scheduler, though in practice most threads of a process are commonly started with the same inherited nice value already.