From owner-freebsd-current@FreeBSD.ORG Fri Jan 20 19:09:01 2006 Return-Path: X-Original-To: freebsd-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 24D7416A41F for ; Fri, 20 Jan 2006 19:09:01 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B012A43D49 for ; Fri, 20 Jan 2006 19:08:58 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp1-g19.free.fr (Postfix) with ESMTP id 64697105ED for ; Fri, 20 Jan 2006 20:08:57 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id k0KJ8mgc007222; Fri, 20 Jan 2006 20:08:54 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 20 Jan 2006 20:08:40 +0100 User-Agent: KMail/1.9.1 References: <43D05151.5070409@elischer.org> <43D0AB26.5070407@samsco.org> <20060120095214.GA11088@xor.obsecurity.org> In-Reply-To: <20060120095214.GA11088@xor.obsecurity.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200601202008.42247.thierry@herbelot.com> Cc: 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: thierry@herbelot.com 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:09:01 -0000 Le Friday 20 January 2006 10:52, Kris Kennaway a écrit : > Correct me if I'm wrong, but the stats aren't accounted to the parent > process either. I'm pretty sure I've seen situations where a thread > was using a lot of CPU, but if you believe top(1) then every process > in the system is idle (except for the fact that the system is 0% > idle). In this situation there's no way to tell which threaded > process is using resources. One work-around is to "nice" the specific process (nice 1 is enough, of course), then the "nice" component of "CPU states:" seems to reflect the real CPU use of a threaded process. TfH