Everyone has either accepted this potential distortion
or patched top to eliminate it. Now, the time has come
to regain some consistency when calculating that %CPU.
We'll now limit such values to: 100.0 * total threads.
And, it took way too long to address this little flaw.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reportshttp://www.freelists.org/post/procps/top-regression-reports,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the increased width and precision of memory and %
columns, the proliferation of 0's when there's nothing
to report seems like a distraction versus useful data.
This commit introduces the '0' toggle which can either
display or suppress those zeros. And, like the scaling
states this new state is also preserved in the rcfile.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is an unrequested outgrowth of the earlier
change dealing with summary area memory field scaling.
That user selectable scaling provision is now extended
to include 6 (at present) task oriented memory fields.
The new companion 'e' (lower case) interactive command
has been added and, like the 'E' command, it can cycle
each of the currently displayed memory columns between
KiB through TiB. There are, however, some differences.
Where '+' indicates summary area truncation at a given
radix, task memory fields are automatically scaled for
their column. Thus, not all rows use the same scaling.
And, while summary area field widths were not changed,
the task memory columns were widened in order to offer
more meaningful data when the radix was increased. The
precision is automatically increased in step with each
radix: MiB displays 2 decimal places, GiB 3 and TiB 4.
To compliment that additional precision, both the %CPU
and %MEM fields were widened by 1 column and now offer
precision up to 3 decimal places. But, unique to %CPU,
widening could already have occurred due to the number
of processors in some massively parallel boxes. At any
rate, total extra width for both memory and percentage
fields could amount to twenty (precious) columns more.
So for both the memory and % fields the original width
(along with loss of precision) can be restored via new
compiler conditionals which this commit also provides.
p.s. and it will be rcfile preserved for any restarts!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reports
Signed-off-by: Jim Warner <james.warner@comcast.net>
Earlier this year, the switch from KiB to Mib as shown
in top's summary area was postponed to those occasions
when KiB exceeded 8 digits. In hindsight that may have
moved top in the wrong direction, given the difficulty
of digesting such large numbers of digits at a glance.
This commit adds a new 'E' interactive command used to
cycle the displayed memory amounts ranging from KiB to
TiB. Thus, users can choose the radix they wish shown.
p.s. and it will be rcfile preserved for any restarts!
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
http://www.freelists.org/post/procps/top-regression-reports
commit 95f2201730
Author: James Cloos <cloos@jhcloos.com>
Date: Mon Feb 6 00:00:00 2012 -0500
Signed-off-by: Jim Warner <james.warner@comcast.net>
This 'Sleeping in function' field was made variable
width because the length of current kernel symbols
usually exceeded the former top's 9 character limit.
As a variable width field it would steal valuable
horizontal display positions from other, more likely,
displayed fields such as COMMAND or CGROUPS.
With the advent of the new 'X' toggle, no fixed-width
non-scalable field need suffer permanent truncation.
Thus, WCHAN is being made fixed width with a default
size of 10 characters.
Signed-off-by: Jim Warner <james.warner@comcast.net>
top/top.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
I have no idea what the maximum length of a terminal
name might be. However, the library provides for up
to 128 characters (ouch).
So just to be safe, this commit extends the ability
to widen columns to embrace this field.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This flaw was revealed under 'man2htm' and dates back
to the first Gitorious revised top submission.
Reference:
commit fd62123562
Date: Thu Mar 31 22:15:12 2011 +1100
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit represents mostly spelling corrections
in comments. It also includes a few very minor logic
changes/relocations.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This section purported to list fields in alphabetical
order, but this was not always true.
With this commit, strict ascii collating sequence is
now observed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
All warnings where about unnecessary quoting. The scriptlet
below will tell what was wrong.
for I in ./top/top.1 ./ps/ps.1 ./*.[0-9]; do
echo "== $I warnings =="
man --warnings=all $I > /dev/null
done
This should probably be turned to 'make check' script.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Since its inception top has provided for monitoring
only specific process ids via the -p command line
switch. This provision has also embraced the top
process itself, even though its pid wasn't yet known.
This commit simply documents the special zero value,
which would otherwise be an invalid process id.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Admittedly, top referred to memory quantities in
a variety of non-standard ways. This commit brings
the program and supporting documentation into strict
compliance with IEC standard binary names.
According to wikipedia, as of 2012 this IEC standard
was still not in widespread use. However, I'm making
this change now for the anal-retentive among us.
Reference:
http://en.wikipedia.org/wiki/Megabyte
Reported by: Roman Mamedov <rm@romanrm.ru>
Bug-Debian: http://bugs.debian.org/662786
Signed-off-by: Jim Warner <james.warner@comcast.net>
