D: uninterruptable sleeping status of a process
dbtouch
Can you give me a system call example which can make a process be in
status "D": uninterruptable sleeping? And if you can explain to me
what exactly the staus is, it will be more helpful.
Thanks,
dbtouch
Lew Pitcher
(dbt...@gmail.com) wrote:
> Dear Linux Developer,
No comment.
> Can you give me a system call example which can make a process be in
> status "D": uninterruptable sleeping?
Examples? Sure...
read()
write()
open()
mmap()
> And if you can explain to me what exactly the staus is, it will be more
> helpful.
There are a number of system calls that the OS can service without delay.
There are a few system calls that the OS cannot complete until resources
become available.
The I/O system calls require that the OS first do something (allocate a
buffer, search for a data block within the cache, etc), then wait for
hardware to do something (read a data block from device, etc) and then do
something more (move data from a cache to a user-space buffer, etc). If one
of those steps hangs (i.e. read errors on the disk cause the disk I/O logic
to hang in read retry), then the process that requested the system call
cannot be placed on the runnable queue, and is marked with a 'D'
(uninterruptible sleep) status.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Josef Moellers
IMHO this isn't sufficient for a process to be placed in the D state.
After all: if it can cleanup after a signal what it has done, then it
doesn't need to be placed in D state, S would be sufficient.
A process is placed in D state if the event the process is waiting is
*guaranteed* to occur (successfully or not) and the cleanup of what the
process has prepared for the event is very complicated or next to
impossible.
E.g. the process has done extensive preparations to read a block from
mass storage, has passed some of its resources to the mass storage
driver and the mass storage driver has a timeout mechanism built in.
The process will be placed in D state because the mass storage layer
will eventually return (maybe with a "timeout" result) and the process
cannot easily reclaim the resources from the mass storage layer.
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html
Rainer Weikusat
> Dear Linux Developer,
>
> Can you give me a system call example which can make a process be in
> status "D": uninterruptable sleeping?
There is no such system call. When a process executing kernel code
needs to wait for an event, it links itself onto a waitqueue, changes
its state from TASK_RUNNABLE to either TASK_INTERRUPTIBLE or
TASK_UNINTERRUPTIBLE and calls the scheduler, which then picks another
process to run. The 'D' state, as shown by ps, corresponds with
TASK_UNINTERRUPTIBLE. This means that the process will only be woken
up when by a 'wake up'-call executed with a pointer to the waitqueue
it is sleeping on as argument. A process in state TASK_INTERRUPTIBLE
will additionally be woken up if a signal is posted to it.
When exactly this happens is entirely at the discretion of the person
who wrote the corresponding kernel code. The most common cause would
be that the process is waiting for disk I/O to complete. Except for
'unusual circumstances' (like disk errors), this can be expected to
always happen after a 'short' time has passed and hence, signals will
be left pending until the waited-for event has occurred. This has the
benefit that system calls which cause disk I/O to happen are not
interrupted by signals and the drawback that 'unusual circumstances'
do happen, for instance, when a disk suddenly stops responding to
commands, and the only cure for this is usually a reboot (provided that
the disk starts to function again after that).
dbtouch
Thank you for the insightful information. My initial guess is that
also I/O related. But I was thinking that large memory operation can
lead process to this status. For example, paging. What status the
process is in when there is page fault?
dbtouch
On Jan 27, 3:04 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
Rainer Weikusat
> Thank you for the insightful information. My initial guess is that
> also I/O related. But I was thinking that large memory operation can
> lead process to this status. For example, paging. What status the
> process is in when there is page fault?
"It depends". Eg, when the page fault is caused because an access to a
non-resident page was attempted, for instance, a page from the text
segment of the program which hasn't yet been read from the
corresponding file or a regular page which is presently swapped out,
the status will change to 'D' until the data has been (re-)read into
memory.