From owner-freebsd-current@FreeBSD.ORG Mon Nov 29 21:14:58 2004 Return-Path: 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 02ABC16A4CE for ; Mon, 29 Nov 2004 21:14:58 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D31DC43D60 for ; Mon, 29 Nov 2004 21:14:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id AD4897A41E; Mon, 29 Nov 2004 13:14:57 -0800 (PST) Message-ID: <41AB9151.8070601@elischer.org> Date: Mon, 29 Nov 2004 13:14:57 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Dan Nelson References: <20041128233704.GB62951@NitroPhys.welchsmnet.net> <20041129154805.GD5518@dan.emsphone.com> <41AB8174.4090205@elischer.org> <20041129205408.GH5518@dan.emsphone.com> In-Reply-To: <20041129205408.GH5518@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Sean Welch Subject: Re: top under 5.3-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 29 Nov 2004 21:14:58 -0000 Dan Nelson wrote: >In the last episode (Nov 29), Julian Elischer said: > > >>Dan Nelson wrote: >> >> >>>The values should total up better when you have processes that hang >>>around a bit more. There was a regression in 5.3's libpthreads that >>>can make it report 0 CPU, so if you have some CPU-hungry threaded >>>programs, they may not show up in top at all even though they're >>>using 100% cpu. libthr and libc_r report CPU correctly. >>> >>> >>As background, libpthread assigns user threads to arbitrary kernel >>threads "as needed". The trouble is that if a user thread comes into >>the kernel, uses a kernel thread, and then exits the kernel and >>another user thread does the same, where can we store the info about >>the first thread? We have no place to store this info in >>libpthreads.. at least not in a form useful to 'top' and 'ps'. >> >> > >Can you just add the stats to the primary kse (the one with id==pid)? > there is no "primary KSE" There is a ksegrp associated with every group of threads that could aggregate this information for all threads under its umbrella, but ps and top don't know about it. >That's always around as long as the process exists afaik. > nope.. once you have switched to threading mode, all threads are the same and the original thread is just as likely as any other thread, to be declared "surplus" and discarded when teh process requires less kernel threads. > Any thread >would do, since you can't guarantee that a thread will use the same kse >twice anyway. What's annoying is seeing a CPU-bound threaded app >(mysql or java, for example) showing 0 %CPU in top/ps but the TIME >column incrementing 1 per second... > understood.. but when 'ps' gets the information, it gets each thread.. where does the info get stored? the threads may have just flashed into existence a fraction of a second ago, and prior to that thay may have belonged to a compeltely different process. It's not a simple problem. However there may be some relatively "ok" answers if we can define well enough what we want to see. For example all taking the total cputime for the KSEGRP and dividing it by the number of non-sleeping threads might be a possibility. (or some variant of that). > > >