Date: Fri, 20 Jan 2006 02:19:34 -0700 From: Scott Long <scottl@samsco.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: current@freebsd.org, Julian Elischer <julian@elischer.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: kernel thread as real threads.. Message-ID: <43D0AB26.5070407@samsco.org> In-Reply-To: <20060120085226.GQ83922@FreeBSD.org> References: <43D05151.5070409@elischer.org> <20060120030105.GA5286@xor.obsecurity.org> <43D0715A.7020302@elischer.org> <20060120061955.GA8687@xor.obsecurity.org> <20060120085226.GQ83922@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote: > On Fri, Jan 20, 2006 at 01:19:55AM -0500, Kris Kennaway wrote: > K> > the example I showed was the 'ps' from ddb which of course doesn't show > K> > any stats anyhow. > K> > K> Yeah, I know that, but they're also not displayed in ps(1) or top(1), > K> etc. > > And this is a serious issue, that is present in our last releases. If a > was a newbie installing FreeBSD for first time, this fact will hurt my > impression about operating system most. > For KSE, threads are just a figment of the imagination of the kernel. A thread that the kernel sees has no specific correlation to a thread that exists in an application. Trying to associate stats with these threads is absolultely meaningless. The processing time accumulated for a particular thread that the kernel sees could well be the aggregate of a number of user threads, and those user threads are likely migrating between the kernel threads. That's the whole point of M:N threading =-) Saying that thread 1 did X amount of work and thread 2 did Y amount of work simply has no meaning, other than that the parent process did X+Y amount of work. For 1:1 threading is does make a little more sense. We'd have to come up with a way to accurately express whether the thread accounting stats are meaningful or not depending on which library is in use. Adding to the complexity would be that KSE can create system and process scope threads, and that system scope threads behave mostly like 1:1 threads. If someone wants to tackle all of this, that would be great, but my only request would be that it can't sacrifice clarity in one library over another library. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D0AB26.5070407>