Calculate effective process priority from nice value and scheduling class.
Linux nice values (-20 highest priority to 19 lowest, default 0) map to CFS scheduling weights via a fixed table (sched_prio_to_weight in the kernel source) where nice 0 = weight 1024 and each nice step changes weight by a factor of roughly 1.25 — not linearly. Under CPU contention, each runnable task's share of available CPU time is approximately its own weight divided by the sum of all competing runnable tasks' weights, which is why a single nice -20 process can dominate CPU time when competing against several nice 0 processes, while the same nice -20 process barely matters if it's the only thing running (nice values only affect relative scheduling under contention, not absolute CPU limits).
CPU share under contention
cpu_share% = task_weight / sum(all_competing_weights) × 100
No — it only increases its relative weight in CFS's proportional-share scheduling among currently runnable tasks; it doesn't grant real-time priority or preempt I/O-bound waiting. For genuine hard real-time guarantees, you'd need SCHED_FIFO/SCHED_RR real-time scheduling policies (via chrt), which operate under entirely different rules than the standard CFS nice-value system.
The kernel's sched_prio_to_weight table is designed so that each single nice-value step changes a task's CPU time share by a consistent ~10% relative factor when running against nice 0 competitors, and this consistent percentage relationship falls out of a roughly exponential (geometric) weight table rather than a linear one.
Not by default — lowering nice (increasing priority) below 0 requires the CAP_SYS_NICE capability, typically only available to root or processes explicitly granted that capability; unprivileged users can only raise their own processes' nice values (lower priority), not lower them, to prevent unprivileged priority abuse.