Skip site navigation (1)Skip section navigation (2)
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>