In the output of top, the state S means interruptible sleep.
What is the state of those processes which are scheduled to be ready and waiting for execution in CPU by the scheduler? Is it S or something else?
Is there a state meaning idle? If yes, does it mean the same as the state of those processes which are scheduled to be ready and waiting for execution in CPU by the scheduler?
The top manpage gives the answer (in the "Process Status" description):
w: S -- Process Status
The status of the task which can be one of:
- ’D’ = uninterruptible sleep
- ’R’ = running
- ’S’ = sleeping
- ’T’ = traced or stopped
’Z’ = zombie
Tasks shown as running should be more properly thought of as ’ready to run’ -- their task_struct is simply represented on the Linux run-queue. Even without a true SMP machine, you may see numerous tasks in this state depending on top’s delay interval and nice value.
Processes which are ready to run show up as R. Truly idle processes, i.e. processes which aren't blocked waiting on I/O (typically) show up as S; processes waiting for I/O show up as D. (This isn't exhaustive, some other waits show up as D too.)
I don't know of a way to differentiate running and ready to run processes.
Strictly speaking the sleep type relates to the possible delivery of signals: if a process isn't running or stopped, it's sleeping; if a signal can be delivered to it immediately, it's "standard" sleep, otherwise it's uninterruptible sleep. See https://stackoverflow.com/questions/223644/what-is-an-uninterruptable-process for more details.
The scheduler doesn't care why a process is not currently runnable.
The S state is used whenever the process has invoked a system call that requires an external event to complete; at this point it does not matter whether the system call itself caused the external event (e.g. a read call), or it just waits (e.g. select or poll).
You can find out which system call the process is waiting in by enabling the WCHAN column in top.
The D state is becoming a bit of a rarity these days, it was generally used if the current system call could not be stopped easily without creating potential data corruption. A notorious example was the NFS client that would go into D state during every file operation, because there is no way to abort a request that may or may not have been received by the server. With more aggressive caching, the cache layer will now see the request through, while the user process is doing something else.
S means idle. S is for “sleep” — the only way for a process to be idle is to be waiting for some event to wake it up. A process that is waiting to be scheduled isn't idle: the reason it would be scheduled is that it has stuff to do.
R means runnable, i.e. a process on the scheduler's queue, executing user land code (i.e. code from the process itself). A process is runnable whether it is currently running or not. You cannot observe the difference between “currently running” and “scheduled to run” from inside the system, because at any given time, the process that is making the observation is running (and thus in state D, or possibly in state R depending on the operating system and the manner that the process uses to observe the status). In order to observe the difference between “currently running” and “scheduled to run”, you would need a kernel debugger.
The third important state is D, meaning “device”. That's the state a process is in while it is busy, but in a system call. A process that is busy executing its own code is in state R; a process that is in a system call and waiting for some event to return from that call is in state S. D is the state of a process that is in a system call and doing something which cannot be interrupted, such as manipulating kernel data structures or transferring data from/to a hardware device. Usually, state D is short-lived, so you won't observe it much unless something goes wrong.
Ps gives a similar description of process states
PROCESS STATE CODES Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a process:D uninterruptible sleep (usually IO) R running or runnable (on run queue) S interruptible sleep (waiting for an event to complete) T stopped, either by a job control signal or because it is being traced Z defunct ("zombie") process, terminated but not reaped by its parent
(I skipped the obsolete ones)
ps -ax -o state,wchan,cmd,pid | tail -n+1| sort |less
should give you a nice snapshot of your processes, sorted by state.
The wchan field shows the waiting channel, which specifies the state of a process more closely.
If you do:
ps -o state,wchan,cmd,pid | tail -n+1| sort |less
it'll show the same info but just for the processes in your terminal session. You can start different processes in the background of your current terminal session and check out what state they're in and what channel they're waiting on:
#this will be waiting on a timer (S hrtime)
sleep 200 &
touch file
#this will get the file lock to `file`, start start sleep and will be waiting on it to complete (S wait)
flock file -c "sleep 100" &
#this won't start sleep because it will be waiting on the file lock (S flock)
flock file -c "sleep 100" &
#ps will be running and the other guys will be waiting o pipe_w
ps -o state,wchan,cmd,pid | tail -n+1| sort |less
Processes that aren't technically waiting on a resource will internally be runnable, but they will still show up as being in the S state (=waiting on the scheduler to put them on a processor core).
You'll only have a few really "running" processes and the number will be limited by the number of CPU cores you've got.
topitself, so it wasn't regarded as a helpful distinction to make. Even now you would only have one per CPU or one per core/hyperthread. – Random832 May 22 '15 at 12:52D, not all of them do: e.g.select(2)puts the process toSstate until the condition waited is satisfied. – Ruslan May 22 '15 at 15:07