From owner-svn-src-head@FreeBSD.ORG Thu Nov 12 14:18:28 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 7C1441065679; Thu, 12 Nov 2009 14:18:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 551168FC0C; Thu, 12 Nov 2009 14:18:28 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0D43046B2C; Thu, 12 Nov 2009 09:18:28 -0500 (EST) Date: Thu, 12 Nov 2009 14:18:27 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20091113010924.M1122@besplex.bde.org> Message-ID: References: <200911030928.nA39SjLx085597@svn.freebsd.org> <20091103214231.H23957@delplex.bde.org> <4AF4B6B2.3090706@delphij.net> <20091111230915.B3510@besplex.bde.org> <20091112050515.GA15002@server.vk2pj.dyndns.org> <20091113010924.M1122@besplex.bde.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@FreeBSD.org, d@delphij.net, Peter Jeremy , svn-src-all@FreeBSD.org, Xin LI , svn-src-head@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 14:18:28 -0000 On Fri, 13 Nov 2009, Bruce Evans wrote: >>> Just print %CPU in %4.0f format when it is >= 99.5 (or whatever rounds to >>> 100.0). This works up to 999.5 %CPU. >> >> Actually, %4.0f works up to 9999.5 %CPU because there's no '.' in the >> result. I think this is an excellent solution. And since FreeBSD >> currently has a hard limit of 64 CPUs, it's unlikely to be exceeded for a >> while. > > Oops. With 128-thread hardware just around the corner, we should be working to scrub assumption of 32 or 64 core limits wherever we find them. I don't know what the next "reasonable" limit is, perhaps 1024, but arrays indexed by MAXCPU are becoming decreasingly useful in that light. The dynamic per-CPU stuff for the kernel addresses some but not all of these problems. Robert N M Watson Computer Laboratory University of Cambridge