Strange top(1) output
Chuck Swiger
cswiger at mac.com
Fri May 13 04:17:48 PDT 2005
Giorgos Keramidas wrote:
> On 2005-05-13 05:41, Chuck Swiger <cswiger at mac.com> wrote:
[ ... ]
>> The only thing I *don't* like is splatting the # of threads onto the
>> end of the process name, seperated by a slash: that makes it
>> remarkably hard to read.
>
> I see.
>
> This is one of those things that you either love or hate, I guess.
> Somebody *did* suggest it while we had problems with the THR column
> being too wide and pushing COMMAND out of the visible area, so I tried
> to use prstat on Solaris 10 for a while to see how things work out.
Maybe we could use this space for longer than 8-char usernames, especially if
the thread count is the usual single digit?
> The output format of prstat is:
>
> 1 2 3 4 5 6 7 8
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> +--------------------------------------------------------------------------------
> | PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
> | 313 daemon 6448K 5584K sleep 58 0 0:11.30 0.2% snmpd/5
> | 3817 root 9016K 6640K sleep 58 0 0:00.08 0.1% cfailover/1
> | 7366 keramida 4240K 3568K cpu1 58 0 0:00.00 0.1% prstat/1
> | 7335 root 3904K 2464K sleep 58 0 0:00.00 0.1% sshd/1
[ Ohgod. Mozilla won't let me reformat this quoted text without making it
un-magic and wrapping it. Lemme leave it as it is and hope for the best. ]
> The format of our top, to make comparisons easier is:
> 1 2 3 4 5 6 7 8
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> +--------------------------------------------------------------------------------
> | PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> |54842 root 1 8 0 2364K 1884K wait 0:09 10.91% 10.69% sh
> | 762 keramida 1 96 0 82432K 31280K select 4:53 0.00% 0.00% Xorg
> |65426 keramida 4 20 0 44240K 34152K kserel 4:12 0.00% 0.00% firefox-b
> | 814 keramida 1 96 0 6188K 4424K select 1:06 0.00% 0.00% wmaker
There's four blanks there, so one could handle usernames up to 11 characters
long. Or else remove the double-space between USERNAME and THR. We could
reclaim another 2 spaces between STATE and TIME, as the overwhelming majority
of states seem to be 6-chars long, as you note below.
FWIW, top on Solaris is:
> 1 2 3 4 5 6 7 8
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> +--------------------------------------------------------------------------------
> | PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
> | 27956 chuck 1 0 0 1808K 1256K cpu/3 0:00 0.73% top
> | 208 root 1 58 0 11M 11M sleep 312:46 0.06% se.sparcv9.5.8
> | 1 root 1 58 0 880K 360K sleep 52:08 0.00% init
> | 194 root 14 56 0 64M 59M sleep 15:31 0.00% nscd
I would zap NICE, and shrink TIME somehow, maybe using a human-readable format.
If a process is nice'd, do what ps does (used to do?) and put a "<" or ">" in
the space after PRI, which already displays the effective priority of the task,
anway. Including the impact of nice as well as the scheduler's dynamic
readjustment....
[ ... ]
> The main differences, minus reordering of the fields are:
>
> - Our STATE column is 8 columns wide, while on prstat it uses 6
> - Our TIME column is 5 characters wide vs. prstat's 9
> - We have THR in a column vs. prstat which uses command/N
> - We have both CPU and WCPU
> - SIZE and RSS in prstat are 1 column shorter
I'd be happier to shrink them and use a "dh -H" style readout, otherwise I
agree with displaying only one of CPU and WCPU. Top is only an approximation
or fixed sampling of dynamicly changing stuff, anyway-- the difference between
the two isn't worth the space it uses.
> The THR column seems a bit of waste in retrospect, because depending on
> the workload of the system it may have just one column of useful data.
Agreed. The question to answer, is how should one display the busiest threads
of a process usefully in the top display? Figuring that one out would be
useful to answering other questions about what top should look like.
>> (Which is fine, curses does a lot of hard work that I'm just as happy to
>> let it figure out.)
>
> Unfortunately, the current top uses very few of the features that a full
> blown curses implementation would have.
Curses by slow accumulation, rather than curses by design? Ick. :-)
--
-Chuck
PS: I would also vote for changing nothing in terms of adding or removing
columns, just zapping the username length check, and try to squeeze the
whitespace down a little to make more room for the COMMAND field.
More information about the freebsd-current
mailing list