From owner-svn-src-all@FreeBSD.ORG Thu Nov 12 19:43:13 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05EF1065698 for ; Thu, 12 Nov 2009 19:43:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id D49188FC22 for ; Thu, 12 Nov 2009 19:43:13 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 07F5BC3FB; Thu, 12 Nov 2009 11:43:14 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (64.1.209.194.ptr.us.xo.net [64.1.209.194]) by idiom.com (Postfix) with ESMTP id BB8922D6012; Thu, 12 Nov 2009 11:43:12 -0800 (PST) Message-ID: <4AFC655E.406@elischer.org> Date: Thu, 12 Nov 2009 11:43:26 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "M. Warner Losh" References: <200911030928.nA39SjLx085597@svn.freebsd.org> <20091103214231.H23957@delplex.bde.org> <20091112.110732.1938114630.imp@bsdimp.com> In-Reply-To: <20091112.110732.1938114630.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 19:43:14 -0000 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. > > 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. > If you select -H (all threads showing), then give it as a% of a single CPU. they can never be > 100% per thread. for non -H show aggregate. > Here's where my bikeshed proximity detector starts beeping... > > Warner