From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:55:54 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9321484B; Thu, 31 Jan 2013 15:55:54 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id ACC9AF6E; Thu, 31 Jan 2013 15:55:44 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r0VFthGH010276; Thu, 31 Jan 2013 08:55:44 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0VFtfPP025065; Thu, 31 Jan 2013 08:55:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: disk wait mystery From: Ian Lepore To: Warren Block In-Reply-To: References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> <20130131142658.GC74563@in-addr.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2013 08:55:41 -0700 Message-ID: <1359647741.93359.335.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Brett Wynkoop , Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:55:54 -0000 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