25

The nice command allows you to adjust the scheduling priority ("niceness") of a program. On all Unix-like systems I've used, niceness is specified by a range of integers, where -20 is the most favourable scheduling priority, 0 is the default, and 19 is the least favourable.

Having 0 as the default niceness is intuitive enough, but why were -20 and 19 selected as endpoints of the range? Why not -128 and 127, which would exactly fit in a signed 8-bit byte? Or why not -100 to 100, which is more intuitive to decimal-minded humans, or similarly but slightly more ergonomically, -99 to 99? Was the -20 to 19 range selected arbitrarily, or does it have some relationship to the internals of the scheduler that nice originally interfaced with? (I understand that there is no such relationship today, at least for Linux, whose scheduler uses priorities in the range 0 to 139. However, I'm interested in the historical reasons for the -20 to 19 range.)

1
  • 6
    I can't find a reference explaining why that specific range was chosen, but note that in V7 the priority fit into a signed byte - see proc.h - and the setpri function set the priority to min(127, (recent CPU usage on a scale of 0 to 15) + 50 + pp->p_nice - 20), and priorities < 25 were reserved for processes doing uninterruptible things. So niceness had to be kind of a limited range. Sep 27, 2015 at 21:16

2 Answers 2

8

Internal niceness levels are 0-39, but increments are positive or negative. Source. So the answer is that the numbers (positive and negative) accepted by the nice command are what get you from 20, the default level, to anywhere in the 0-39 range.

So why 0-39? The specific range was what worked in the designers' original implementation. The reason more positive values are nicer is that the nice level is added to a process's recent CPU usage in determining priority. In order to provide approximate round-robin scheduling, the kernel keeps track of how much CPU each process had burned recently and switches to processes that haven't had as much. The higher the nice level, the more CPU time it looks like the process has had, and the more often the scheduler will put that process to sleep or leave it asleep. See The Design of the UNIX Operating System by Maurice J. Bach, Prentice-Hall 1986, sec. 8.1 (8.1.4 for niceness specifically). ISBN 0-13-201799-7.

1
  • 1
    You are mistaken when assuming that the scheduler will put a process to sleep if it has a bad nice value. Instead, the scheduler will not wake up a sleeping process if there are other processes ready to run and these processes have a better nice level. Note that a process is put to sleep, when it either calls a syscall that enforces a sleep on resources or when a process used up it's CPU quantum and there are other more privileged processes waiting for the CPU.
    – schily
    Sep 27, 2015 at 22:13
-4

You are mistaken: If you are on a UNIX where the nice() interface still makes sense, NZERO is the default nice value and NZERO is 20.

To make thing more obvious: you asked about the command nice and at the same time mentioned absolute levels, but the nice command does not manage absolute values but rather increments relatively to the current level. In case of the default state, the nice level is NZEROwhich is 20.

Nice values are 0..2*NZERO-1 or 0..39

Note that while the default UNIX scheduler may still be able to do something useful with a nice value, there is no meaning in case you are using a specialized scheduler, e.g. a realtime scheduler.

2
  • 2
    You seem to be confusing the shell interface and the C interface. This question is about the nice shell command. Sep 27, 2015 at 20:28
  • Well it is you who confuse things.The nice command only knows about deltas but the question mentions nice values. The question was about nice values and I answered this.
    – schily
    Sep 27, 2015 at 21:48

You must log in to answer this question.

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