svn commit: r198848 - head/bin/ps

[Bruce Evans]

On Tue, 3 Nov 2009, Xin LI wrote:

> Log:
>  Increase width for %CPU, RSS and VSZ columns for now.  Modern systems
>  tend to have larger memory, larger process, and more CPU.

This uses space that is not available.  Command names(+args) are now
truncated to 9 columns in "ps l" output :-(.  They used to be truncated to
11 columns recently (down from 12 columns in FreeBSD-5.2).

%CPU != CPU.  Modern systems don't really have more %CPU.  The maximum
percentage of anything is still 100.0.  However, there are various bugs
that result in a percentage of 100.0 being misdisplayed and "percentages"
of more than 100.0 occurring:
- ps used %4.1f format.  This works for all percentages <= 99.9 (after
   rounding), but not for 100.0.  Now ps uses %5.1 format, so 100.0 is
   displayed correctly, but all normal percentages are displayed worse
   than before (space that is not available is used to make them harder
   to read).
- %CPU is not divided by the number of CPUs.  Thus a multi-threaded
   process can have %CPU almost as large as <number of CPUs> * 100.0.
   This might be a feature.  E.g., on mostly-idle systems, the idle
   process consists of <number of CPUs> threads which take akmost
   100.0% CPU each, so the total %CPU for the idle process is almost
   the above maximum (it is now 799.2 on ref8.freebsd.org due to ref8
   having 8 mostly-idle CPUs).  Since ps now uses %5.1 format, it can
   display %CPU correctly on all systems with <= 9 CPUs, and on most
   systems with 10 CPUs (since the value of 1000.0 which is too wide
   for %5.1 format is even harder to reach on a 10-CPU system than
   the value of 100.0 which is too wide for %4.1 format is to reach on
   1 a-CPU system).  The format is still broken on systems with >= 11 CPUs.
- perhaps schedular bugs can result in %CPU being transiently slightly
   greater than 100.0 for an individual thread.

Expanding %CPU doesn't truncate "ps l" since "ps l" doesn't print %CPU.
Thus the recent truncation is only from 11 COMMAND columns to 9 instead
of to 8.

There seems to be no better fix than to further granulate and dehumanize
the numbers so that they fit in the available space.  E.g., a %CPU of
>= 100 and < 9999 should be displayed in %4.0f format; this only
involvues granulation, but above 9999 it needs to be dehumanized as
well and displayed in k or M or larger granularity (it can be > 9999
with 100 CPUs and > 999k with 10000 CPUs).  A VSZ of >= 10000 (k
implicit) needs to be displayed in M or larger granularity (M explicit).

Bruce