Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jun 2003 09:33:18 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        arch@freebsd.org
Subject:   Re: marking normal sleep identifiers as such.
Message-ID:  <Pine.NEB.3.96L.1030618092937.4523A-100000@fledge.watson.org>
In-Reply-To: <36655.1055917248@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 18 Jun 2003, Poul-Henning Kamp wrote:

> Now that we have a bunch of kernel threads which participate in the
> running of the system, I find that it is a tad more time consuming to
> figure out what the state of a crashed or hung system is. 
> 
> So I was wondering if we should instigate a simple convention for the
> sleep identifiers to make it easier to spot, or rather: ignore, kthreads
> which are in their normal idle position. 
> 
> Since thread names are longer than the space we have in ps(1) output
> using the thread name is not feasible solution. 
> 
> I notice that the interrupt threads all seem to sleep on "-", and all
> things considered, I like that. 
> 
> Should we adopt that as our convention ? 

I agree with the concern -- I've similarly noticed an increase in the
amount of time I spend diagnosing apparent deadlocks as I attempt to
determine if kernel threads are simply idle, or stuck on locks.  I don't
really mind what the convention is; "-" is probably as good as any. 
Another possible convention would be to name the state fooidle -- i.e.,
pageridle, acpiidle, ...  Given that the purpose of the thread is
documented in the thread name, generally, this is probably overkill and
unnecessarilly extends the number and length of strings involved.  A final
option that comes to mind would be simply to call the state "idle".  One
disadvantage of changing to a common name with no distinct string is that
it makes it quite a bit harder to track down the sleep call in the kernel;
you can no longer glimpse/grep on the state to find the stage in the
thread event loop you've reached, which would be one reason to prefer a
fooidle approach.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030618092937.4523A-100000>