disk wait mystery

[Ian Lepore]

On Thu, 2013-01-31 at 08:02 -0700, Warren Block wrote:
> On Thu, 31 Jan 2013, Gary Palmer wrote:
> 
> > On Thu, Jan 31, 2013 at 07:12:44AM -0700, Warren Block wrote:
> >> On Wed, 30 Jan 2013, Andrew wrote:
> >>
> >>> On 30 Jan 2013, at 17:05, Brett Wynkoop wrote:
> >>>
> >>>> I appreciate the education on this point!  I wonder if this should be
> >>>> considered a man page bug?
> >>>
> >>> The man page does say "(or other short term, uninterruptible) wait". I
> >>> don't know what sort of wait the kernel threads may or may not be in
> >>> but if they are in one, and its short-term then the man page is
> >>> correct. Maybe an FAQ entry though.
> >>
> >> If the man page is misleading or incomplete, it should be fixed.  Based
> >> on the source, the mention of disk at the start is misleading.  Maybe:
> >>
> >> D       Marks a process in short term, uninterruptible wait.
> >>
> >> Or
> >>
> >> D       Marks a process in short term, uninterruptible wait (typically,
> >>          disk wait).
> >>
> >> Which explains the "D" but may reintroduce the confusion.
> >
> > D       Marks a process in short term, uninterruptible wait (In non-kernel
> >        processes, this is typically waiting on disk I/O)
> 
> The followup question that creates is "what are kernel threads waiting
> on?"  Which is covered by the uninterruptable part earlier.  I think the
> "typically" handles it without creating more questions.
> 
> Leaving out the redundant "Marks a process" wording:
> 
> D	Disk wait, or other short-term, uninterruptable wait.
> 
> "disk wait" was the original term in that man page.  "Also shown for 
> uninterruptable kernel threads." is just repeating.

If there's going to be any attempt to reconcile the use of the letter
'D' I think the term "device" would be more accurate these days than
"disk".  

>From a glance at the code, I think this state would be reported for any
userland thread that's sleeping in a driver that called one of the
sleep(9) family functions without the PCATCH flag which allows signals
to interrput the sleep so they can be delivered to userland.  For kernel
threads I think the PCATCH part is moot and it's just a thread in a
"short" sleep (for some definition of short).

-- Ian