Date: Thu, 12 Nov 2009 14:18:27 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@FreeBSD.org, d@delphij.net, Peter Jeremy <peterjeremy@acm.org>, svn-src-all@FreeBSD.org, Xin LI <delphij@FreeBSD.org>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r198848 - head/bin/ps Message-ID: <alpine.BSF.2.00.0911121416230.11129@fledge.watson.org> In-Reply-To: <20091113010924.M1122@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0911121416230.11129>