Date: Wed, 12 Jun 2013 10:39:06 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r251630 - head/usr.bin/top Message-ID: <20130612094322.T966@besplex.bde.org> In-Reply-To: <201306111905.r5BJ5TGv055136@svn.freebsd.org> References: <201306111905.r5BJ5TGv055136@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Jun 2013, John Baldwin wrote:
> Log:
> Bump the CPU/WCPU column width by one so that it fits values from 100% up
> to 999.99% CPU. It still won't be aligned if you have a multithreaded
> process using more than 1000% CPU (e.g. idle process on an idle 12-way
> system), but 100% is a common case.
>
> Submitted by: Jeremy Chadwick (partial)
> MFC after: 1 week
There was a negative amount of space available for expansion. The COMMAND
field was down to 7 columns. Just enough to not truncate its own name.
top doesn't support much window sizing. It doesn't support the COLUMNS
environment variable, and its non-interactive output still truncates the
COMMAND column by formatting for 80-column terminals. OTOH, systat
makes a mess of the screen when COLUMNS is set to a non-physical value,
since it uses full curses.
ps has similar bugs. ps l still has 15 columns for COMMAND, but ps
doesn't remove path prefixes like top does, so command names like
/usr/libexec/getty were shifted out of the screen/window long ago.
systat handles this problem to some extent using special format routines
that switch the format if the default one wouldn't fit. IIRC, it handles
the rare case of 100.0% idle by switching the format to 100%. It has to
do more complicated switches for numeric values that can range from 0 to
millions and need to be displayed in 3 or 4 columns.
While here, I will complain about someone breaking ruptime using a grossly
large fixed-width field for the machine name. Other field widths (just
the time?) can vary, so sometimes (after several days of uptime?) the full
width is 80 columns so it wraps especially horribly on 80-column terminals
with auto-wrap.
There is plenty of space to spare in ruptime. I thought that top had
dynamic sizing for its USERNAME column, but on freefall now this column
is very wide. There is just one long name in it ("auditdistd") and
several unnecessary spaces even for that. This accounts for all of the
8 lost columns in its COMMAND field compared with my local system.
Also, vmstat -i was broken for some arches by right-padding interrupt
names with spaces. vmstat doesn't understand the spaces, so its
autosizing of the name column has no effect (it uses strlen() to
determine the maximum width needed, but strlen() counts the spaces).
top's dynamic sizing seems to be broken in a different way by its naive
use of strlen(). It seems to search the entire password database to
find the longest name according to strlen(). It takes the minimum of
the result of this and either SMPUNAMELEN = 13 or UPNAMELEN = 15.
It also has a lower limit of 8 (so the field has space for its own
name, unlike COMMAND now) and an option TOP_USERNAME_LEN to change
the lower limit. On a system with many users, the search wastes time
searching the password database for a value that will always be larger
than 15. Someone will have a long name. If the system allowed, then
jokers would right-pad their names with spaces to confuse utilties.
The magic difference of 2 between SMPNAMELEN and UPNAMELEN seems to
be broken too. I think the C field width used to be 2 and this difference
allowed for its addition by stealing space from the USERNAME field.
But now there are systems with more than 9 cores and the C field width
is 3.
User names should be truncated to width TOP_USERNAME_LEN (default 8).
They are much less important than command names. If you want dynamic
sizing and slowness, search all active usernames and all active
command names to find the best combination of widths on every refresh.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130612094322.T966>