I know what 'nice' is and how it maps to priority, this is not the question.

Linux priorities range from 0-139. 0-99 is real time, 100-139 is user space. Nice maps onto priority:

  • -20 → 100
  • 0 → 120
  • +19 → 139

I understand nice is user space, priority is kernel space.

But why bother with the notion of 'nice'? it seems to be a redundant measure. Under what situation would having nice be better than just simply directly influencing priority?

Is it there simply for convenience or is there a technical reason for having it?

  • 2
    It seems to me that nice is a way, indeed the [portable] way, of "directly influencing priority". By the way, real time and user space are not mutually exclusive: you can have user space processes that are real time and I also guess that you can have kernel threads that aren't.
    – Celada
    Jun 24, 2015 at 14:14

1 Answer 1


The nice(2) syscall is changing the relative priority (from what it was before that syscall). But setpriority(2) is changing the absolute priority.

So my understanding is that nice(x) (with x being a very small number, e.g. between 0 and 9) is the equivalent of atomically doing:

// asssume both getpriority & setpriority syscalls are successful
int n = getpriority(PRIO_PROCESS, 0);
n += x;
setpriority(PRIO_PROCESS, 0, n);

Since several processes could do likewise on the same process (e.g. calling setpriority(PRIO_PROCESS, somepid, n); ....), you'll bettter have an atomic operation combining them, and that is nice(2)

But the main reason is legacy and history (and backward compatibility). IIRC, in the 1980s old Unix (like SunOS3.2) had nice but no setpriority (but I might be wrong).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .