Date: Thu, 12 Nov 2009 11:07:32 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: brde@optusnet.com.au 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 Message-ID: <20091112.110732.1938114630.imp@bsdimp.com> In-Reply-To: <20091103214231.H23957@delplex.bde.org> References: <200911030928.nA39SjLx085597@svn.freebsd.org> <20091103214231.H23957@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091112.110732.1938114630.imp>