From owner-freebsd-current@FreeBSD.ORG Fri Jan 20 19:28:35 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 BBA1A16A41F; Fri, 20 Jan 2006 19:28:35 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7673543D46; Fri, 20 Jan 2006 19:28:35 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 20 Jan 2006 11:28:34 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43D139E2.6020009@elischer.org> Date: Fri, 20 Jan 2006 11:28:34 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long 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> <20060120095214.GA11088@xor.obsecurity.org> <43D13711.9000509@elischer.org> <43D138C0.9040801@samsco.org> In-Reply-To: <43D138C0.9040801@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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:28:35 -0000 Scott Long wrote: > Julian Elischer wrote: > >> Kris Kennaway wrote: >> >>> >>> 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. >>> >>> >> >> you may be right.. I plan to examine stats over the next week as part >> of the kernel threads work. >> I may be able to improve the situation. >> > > Um, would this be considered a security flaw, since process time limits > likely aren't being enforced? I won't know before looking but some accumulation of sats to teh process is happenning already (but not being shown) so it may still be being enforced.. it's not that simple. > >> my aim is that for threads that are doing M:N work the stats will >> accumulate on the thread >> for a short while and then be collected to the KSEG when ther eis >> reason to think that >> the kernel thread has changed purpose or exits (both of which happen >> a lot in KSE). >> >> for 1:1 threads, they will continue to accumulate on the thread, >> since no "KSE events" will >> occur. >> >> The KSEGRPs stats will be collected to the process when asked for. >> I will probably also change the way that 'ps' shows these (and >> threads). I'm not sure what to do about top yet. we really need to be >> able to show a >> process name AND a thread name when the threads are shown and have >> names. >> >>> Kris >>> > > Does pthreads allow the programmer to name threads in a user and/or > kernel visible way? Is this something that is really all that > important? There is a way, but it's more important for kernel threads.. it's nice to see which is which. Even in user threads (1:1) if one thread is running away, it's nice to see which one it is. We should have an interface on M:N thread sto allow a process to get thread stats.. probably implemented as a management thread or something. (maybe the signal thread could do it). > > Scott