From owner-svn-src-head@FreeBSD.ORG Thu Nov 12 18:17:41 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 F0D8B1065692; Thu, 12 Nov 2009 18:17:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AFBE68FC0A; Thu, 12 Nov 2009 18:17:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id nACI7JhN060710; Thu, 12 Nov 2009 11:07:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 12 Nov 2009 11:07:32 -0700 (MST) Message-Id: <20091112.110732.1938114630.imp@bsdimp.com> To: brde@optusnet.com.au From: "M. Warner Losh" In-Reply-To: <20091103214231.H23957@delplex.bde.org> References: <200911030928.nA39SjLx085597@svn.freebsd.org> <20091103214231.H23957@delplex.bde.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, delphij@FreeBSD.org 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 18:17:42 -0000 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. 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. 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... Warner