From owner-freebsd-current@FreeBSD.ORG Fri Jan 20 19:25:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFFB716A41F; Fri, 20 Jan 2006 19:25:08 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 509B143D46; Fri, 20 Jan 2006 19:25:08 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id k0KJP5Er014060; Fri, 20 Jan 2006 14:25:05 -0500 (EST) Date: Fri, 20 Jan 2006 14:25:05 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <43D13500.1030904@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Gleb Smirnoff , current@freebsd.org, Kris Kennaway Subject: Re: kernel thread as real threads.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2006 19:25:08 -0000 Julian or Scott wrote: > > 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. The stats are kernel stats, not userland stats. I see no harm in showing (or keeping track of) stats for threads that are M:N. It doesn't matter what kernel thread the userland threads run on, or whether they migrate or not, at least not for purpose of showing stats for kernel threads. When you look at the output of 'ps', 'top', or whatever, you just have to realize it is the view as seen by the kernel. -- DE