Re: Strange top(1) output

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.