Date: Fri, 20 Jan 2006 11:07:44 -0800 From: Julian Elischer <julian@elischer.org> To: Scott Long <scottl@samsco.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: kernel thread as real threads.. Message-ID: <43D13500.1030904@elischer.org> In-Reply-To: <43D0AB26.5070407@samsco.org> References: <43D05151.5070409@elischer.org> <20060120030105.GA5286@xor.obsecurity.org> <43D0715A.7020302@elischer.org> <20060120061955.GA8687@xor.obsecurity.org> <20060120085226.GQ83922@FreeBSD.org> <43D0AB26.5070407@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > 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. maybe ps can put '--.--' or 'N/A' for threads with M:N flags on them. > > 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. I plan to tackle this as part of what I'm doing with kernel threads I've done all I can do this week but will probably to the stats part next week. > > Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D13500.1030904>