Calculate the renice adjustment needed to shift a running process's CPU scheduling priority.
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.
Weight change and CPU share impact
weight_change_ratio = new_weight / current_weight; cpu_share_change% = (weight_change_ratio − 1) × 100
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.
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.
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.