From owner-svn-src-head@FreeBSD.ORG Thu Nov 12 20:09:19 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AA3F1065672; Thu, 12 Nov 2009 20:09:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 352598FC12; Thu, 12 Nov 2009 20:09:18 +0000 (UTC) Received: from besplex.bde.org (c220-239-235-116.carlnfd3.nsw.optusnet.com.au [220.239.235.116]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nACK9CDt025376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 07:09:13 +1100 Date: Fri, 13 Nov 2009 07:09:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "M. Warner Losh" In-Reply-To: <20091112.110732.1938114630.imp@bsdimp.com> Message-ID: <20091113065648.K2448@besplex.bde.org> References: <200911030928.nA39SjLx085597@svn.freebsd.org> <20091103214231.H23957@delplex.bde.org> <20091112.110732.1938114630.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, delphij@FreeBSD.org, brde@optusnet.com.au Subject: Re: svn commit: r198848 - head/bin/ps X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 20:09:19 -0000 On Thu, 12 Nov 2009, M. Warner Losh wrote: > I'd argue that as we get more and more cores that %CPU will need to > change. > > If we change it like Bruce suggests, then when we have 1024 > core/thread processors the 'pegged' thread shows up as 0.09% of the > CPU and likely nothing else shows up at all since the usages are > diluted by a factor of 1024. You mean, like I said not to. > However, for the 'TOP' display, 102400% of the CPU seems like a crazy > thing to report, even if it is consistent with what other systems > report for fewer cores going back to 1980's when VMS reported up to > 200% CPU for the VAX 11/785 on both BSD and VMS. 102400 isn't a very large number. 1M CPUs would give a more interesting number. Anyway, displaying %CPUs is the least of the problems in displaying many threads in top. top has the same problems as systat -p, but more so. It wants to display the top active threads, while systat -p only wants to display the top active threads if they are active enough to be considered pigs. You need the 6 metre high terminal to display the 1024 idle threads for top -SH. If you only want to display user threads then you will still need O(ncpu) lines to display enough active ones if all of the CPUs are actually used. > Likewise, we have issues with our current TOP display eating up a > bunch of columns for 55670k of core when 56M would generally give the > same info to the user (I say generally, because the former is useful > in watching for memory leaks). > > Maybe we just need to have top offer different views into this data > for the different needs that people have for it. A 'detailed' view > that helps expose even small differences that is useful in > development, and a 'condensed' version that gives more of the general > sense of what's going on in the system in a more concise format, but > might lack some of the details found today. > > Here's where my bikeshed proximity detector starts beeping... Adding all the different views would take a lot of paint and many would not like its color. I just want to avoid changing the standard view to one that works worse for small configurations. Bruce