UNIX System Administration Handbook - Evi Nemeth [41]
Table 4.2 Process states
A runnable process is ready to execute whenever CPU time is available. It has acquired all the resources it needs and is just waiting for CPU time to process its data. As soon as the process makes a system call that cannot be immediately completed (such as a request to read part of a file), UNIX will put it to sleep.
Sleeping processes are waiting for a specific event to occur. Interactive shells and system daemons spend most of their time sleeping, waiting for terminal input or network connections. Since a sleeping process is effectively blocked until its request has been satisfied, it will get no CPU time unless it receives a signal.
Stopped processes are administratively forbidden to run. Processes are stopped on receipt of a STOP or TSTP signal and are restarted with CONT. Being stopped is similar to sleeping, but there’s no way to get out of the stopped state other than having some other process wake you up (or kill you).
4.6 NICE AND RENICE: INFLUENCE SCHEDULING PRIORITY
The “niceness” of a process is a numeric hint to the kernel about how the process should be treated in relationship to other processes contending for the CPU. The strange name is derived from the fact that it determines how nice you are going to be to other users of the system. A high nice value means a low priority for your process: you are going to be nice. A low or negative value means high priority: you are not very nice.
The range of allowable niceness values varies among systems. The most common range is -20 to +19. Some systems use a range of a similar size beginning at 0 instead of a negative number (typically 0 to 39). The ranges used on our example systems are shown in Table 4.3.
Table 4.3 How to express priorities for various versions of nice and renice
a. Uses absolute priority, but adds 20 to the value you specify.
Despite their numeric differences, all systems handle nice values in much the same way. Unless the user takes special action, a newly created process inherits the nice value of its parent process. The owner of the process can increase its nice value but cannot lower it, even to return the process to the default niceness. This restriction prevents processes with low priority from bearing high-priority children. The superuser has complete freedom in setting nice values and may even set a processes’s niceness so low that no other process can run.
On some systems, the kernel will automatically boost the nice value of processes that have accumulated “excessive” CPU time or that have been put in the background.
Manually setting process priorities is quickly becoming a thing of the past. When UNIX ran on the puny systems of the 1970s and 80s, performance was most significantly affected by which process was on the CPU. Today, with more than adequate CPU power on most desktops, the scheduler usually does a good job of servicing all processes. Unfortunately, I/O performance has not kept up with increasingly fast CPUs, and the major bottleneck on most systems has become the disk drives.
See Chapter 25 for more information about performance.
A process’s nice value can be set at the time of creation with the nice command and can be adjusted during execution with the renice command. nice takes a command line as an argument, while renice takes a PID or (sometimes) a username.
Some examples:
% nice +10 ~/bin/longtask
% renice -5 8829
Unfortunately, there is little agreement among systems about how the desired priorities should be specified; in fact, even nice and renice from the same system usually don’t agree. Some commands want a nice value increment, whereas others want an absolute nice value. Some want their nice values preceded by a dash. Others want a flag (-n), and some just want a value.
To complicate things, there is a version of nice built into the C shell and some other common shells (but not sh). If you don’t type the full path to the nice command, you’ll get the shell’s version rather than the operating system’s. This can be confusing