Since the decision was made to also add that Linux-4.5
support (was only in this newlib branch) to our master
branch, a tweak to newlib's top is necessary. In order
to share the rcfile between them, any fields unique to
a branch must appear last in it's list of enumerators.
And the troublesome field in question above is CGNAME.
It doesn't matter if a unique field is on or off, only
that it, as a higher enum/char, appear after all other
shared fields. Otherwise one risks the 'corrupt' error
message from the top without that field or the display
of the wrong column in the top with that unique field.
[ and strictly speaking, the changes under top_nls.c ]
[ were technically not really necessary. however, we ]
[ choose to maintain strict ordering via enum value. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch represents the following minor adjustments:
. the official PROCPS_MEMINFO_VAL macro has become the
basis for our own abbreviated MEM_VAL derivative macro
just like was done for all the other newlib interfaces
. it felt like time to change those forest_?? function
names while maintaining their special relationships to
one another (alphabetic, with each 1 longer than prev)
. and some whitespace was altered and some lines added
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just brings *most* other programs into line
with those changes recently made in the <meminfo> API.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This guy is the real beneficiary of the new <stat> API
especially when it comes to the DELTA items which were
really the only values of interest (beyond some id's).
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit contains the following changes, which were
prompted by a coverity analysis which Craig initiated:
. comment typo predicting 'String not null terminated'
. eliminate 'Logically dead code' from insp_make_row()
And this tweak unrelated to coverity is also included:
. use more modern (recommended) approach for time call
Signed-off-by: Jim Warner <james.warner@comcast.net>
All other programs were able to accommodate the change
in name from readstat.h to stat.h without modification
because they were all using that procps.h header file.
Well now top can too (providing you ignore a comment).
Signed-off-by: Jim Warner <james.warner@comcast.net>
Rather than importing NORETURN & MALLOC, it feels more
natural to use the native gcc attribute for NORETURN &
eliminate the use of a questionable MALLOC altogether.
Reference(s):
commit ccb6ae8de1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and more attention recently paid to the 2 oomem fields
it was revealed that Rc.zero_suppress didn't extend to
them. So this commit will just correct that oversight.
And while we're at it, we'll also extend zero suppress
to that NI (nice value) field, which already should've
had it. Plus we trade those namespaces custom suppress
logic for our now slightly enhanced make_num function.
Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
. zero suppression only recently added to namespaces
commit b2853ed117
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and all users exposed to those 'out of memory' fields,
it's about time we added them to the top man document.
But before doing so, it's long past time that they are
normalized to at last remedy this kind of foolishness:
. excessive width on that oomem score itself (8 vs. 4)
. some potentially confusing names inherited from suse
Reference(s):
. removal of misguided OOMEM_ENABLE
commit 64238730fa
Signed-off-by: Jim Warner <james.warner@comcast.net>
The includes used to define a lot of things a library include
should not. It was also a bit messy what was exposed in the library
and what was not.
get_pid_digits -> procps_pid_length and exported correctly
MALLOC attribute move into relevant .c files
NORETURN attribute moved to relevant .c, not used in library
PURE attribute removed, it wasn't used
KLONG/KLF/STRTOUKL were fixed for long, so now just use long
HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT
seems to do the same (opposite) thing.
likely/unlikely removed from most places, its highly debateable
this does anything useful as CPUs have gotten smarter about branches.
Re-arranged the includes, ALL external programs should just #include
<proc/procps.h> then proc/procps.h includes headers for files that
have exported functions. procps.h and the headers it includes should
not use items that are not exportable (e.g. hidden functions or
macros) they go in procps-private.h
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.
p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
This patch just represents the initial library and top
support, sharing a commit message with 2 more patches.
p.s. locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
Reference(s):
commit 1f8e41d019
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ patch has been adapted expressly for newlib branch ]
In response to Issue #21, the commit referred to below
provided some much needed improvements and corrections
to topic `3a. DESCRIPTIONS of Fields' in the man page.
However, it assumed a reader possessed much background
knowledge that may not, in truth, actually be present.
So without, hopefully, insulting anyone's intelligence
this patch offers an expanded discussion of some terms
and concepts within a separate section under OVERVIEW.
[ plus it affords an opportunity to incorporate that ]
[ extremely useful table from Florent Bruneau's post ]
Reference(s):
commit 6a36bd7afdhttps://techtalk.intersec.com/2013/07/memory-part-1-memory-types/
Signed-off-by: Jim Warner <james.warner@comcast.net>
Due to quirks in kernel memory management plus limited
information available from /proc/<pid>/status & statm,
some of the top resident memory fields were capable of
exceeding available physical memory. So this commit is
a bit of a band-aid until the kernel has been changed.
Such a change appears to be on the horizon in the form
of three new fields to be added to /proc/<pid>/status.
While not preventing 'resident' memory from apparently
exceeding physical memory, the new fields will help to
clarify any such contingency, if/when we exploit them.
Reference(s):
. original post by Samuel Thibault
https://gitlab.com/procps-ng/procps/issues/21
. informative memory analysis
https://techtalk.intersec.com/2013/07/memory-part-1-memory-types/https://techtalk.intersec.com/2013/07/memory-part-2-understanding-process-memory/
. kernel changes to /proc/<pid>/status
commit 8cee852ec53fb530f10ccabf1596734209ae336b
commit eca56ff906bdd0239485e8b47154a6e73dd9a2f3
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit referenced below claims to disable vertical
scrolling when idle tasks weren't being shown. However
it really addresses only a point in time when that 'i'
toggle is keyed. Left untouched were the up/down keys.
So this commit will simply finish the job of disabling
vertical scrolling whenever tasks which have used some
CPU are the only ones which are currently being shown.
Reference(s):
commit c07f6c5e6d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit is just a cleanup of some extraneous cruft
left after the newlib migrations and summarized below:
. whack the 2nd line of what was an eliminated comment
. eliminated reference to NUM_NS and thus that need to
include the otherwise defunct 'readproc.h' header file
. reference to Frame_maxtask made properly generalized
. all former sort support #define's are now eliminated
Signed-off-by: Jim Warner <james.warner@comcast.net>
[ but stay tuned! there is a commit coming soon that ]
[ represents a rather major internal redesign, which ]
[ was prompted by the ps and top adaptation testing. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
It is documented behavior that when certain other keys
are active, sorts column highlighting will temporarily
be disabled. Among those keys is the 'L' (locate/find)
provision. The equals ('=') key can be used to restore
column highlighting by resetting other keys, except 1.
When a locate/find is active, the '=' key will have no
effect on 'x' column highlighting, which still remains
disabled. Further, when 'L' is active an 'x' keystroke
is processed changing the state of column highlighting
but without any visual clue (since it's yet disabled).
So this commit just extends the '=' key to embrace 'L'
processing resets, just like other highlight disabling
keys while avoiding 'x' state changes if approproiate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ever since top was adapted to the new <pids> interface
there has been a bug that would cause an abnormal exit
when the '-p' argument contained *no* valid pids. This
was never revealed until now since the QA folks tested
only with valid, existing pids. (bunch of morons, eh?)
And even though the program author is blameless he has
taken it upon himself to clean up after the QA jokers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Two separate entries under the Fieldstab were employed
to manage 'relative' enumerators under that new <pids>
interface. However, just a single entry could actually
serve both needs with a negative 'not selected' value.
So this commit just borrows the approach used with the
ps conversion where -1 is now representing unselected.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just eliminates an error message no longer
needed under that newlib <pids> interface. Plus, a few
enumerators in the header weren't in alphabetic order.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the advent of the 'fatal_proc_unmounted' function
in the <pids.h> API to ensure the /proc filesystem was
mounted, we will finally get rid of the last remaining
vestiges of the former libprocps <readproc> interface.
[ also play a little catch up and whack some headers ]
[ that are not necessary now, beyond that readproc.h ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whoa, guess what field got overlooked in that march to
the newlib conversion? It was the TTY guy. However, it
wasn't completely top's fault - that newlib must share
at least some responsibility, for only offering a num.
[ and while we're at it, let's touch up the man page ]
[ to agree with ol' newlib's current implementation. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When top was originally adapted to use that <pids> API,
the forest view support was redesigned since the proc_t
pad_3 byte could no longer be employed to hold a task's
nesting level. The redesign required additional arrays.
Now that the dust is settling on those initial efforts,
that PROCPS_PIDS_noop item was used as a substitute for
the old pad_3 along with a return to the former design.
But, while it proved adequate, the invariant nature for
that item required of top an extra initialization step.
So the library was coaxed into adding one more pid_item
(PROCPS_PIDS_extra) which will, unlike that 'noop' guy,
be reset with each reap. Everybody should be happy now.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Craig's recent commit under that newlib branch dealing
with namespace support has prompted me to review top's
handling of those fields. Currently, when such a field
is zero, top displays a dash ('-'). This will mean the
justification toggles ('j/J') will behave incorrectly.
This patch simply allows the potential zero to display
or be suppressed with the already existing '0' toggle.
Signed-off-by: Jim Warner <james.warner@comcast.net>
A patch containing the following miscellaneous tweaks:
. remove a function that handled former library errors
[ that function should have gone bye-bye with 3.3.11 ]
[ when those 'wchan' provisions were much simplified ]
. make clearer a distinction between 'new' and 'reset'
[ use PROCPS_PIDS_noop when procps_pids_new() called ]
[ since at that point we are only establishing depth ]
Reference(s):
http://www.freelists.org/post/procps/newlib-for-pgrep,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
A patch containing the following miscellaneous tweaks:
. exploit (actually adapt) a pids.h provided VAL macro
. remove some obsolete, now unused, sort related items
. clarify the comment for specialized extractor macros
Signed-off-by: Jim Warner <james.warner@comcast.net>
Just in case, make the old proc_t used in the before()
function static so valgrind doesn't get his panties in
a bunch over the fact the 'cmd' is now dynamic memory.
[ Shouldn't that function, or an equivalent, also be ]
[ part of our new library's implementation? However, ]
[ is it proper for a brand new library to abnormally ]
[ terminate a calling process with a stderr message? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
It was probably always wrong to have a variable length
proc_t structure. This patch takes all remaining oomem
former suse only options and makes them unconditional.
Signed-off-by: Jim Warner <james.warner@comcast.net>
. didn't need a separate table for enum pids_reap_type
since top's 'Thread_mode' itself can be used directly.
. with pids support & the loss of forest_based(), that
forest_adds() function had to be renamed so the prolog
comment regarding naming convention was still honored.
. adapted to a library change to the pids_reap struct.
Signed-off-by: Jim Warner <james.warner@comcast.net>
TOP, respond to library change to the pids_reap struct ...
Signed-off-by: Jim Warner <james.warner@comcast.net>
The newlib informal cutoff for kernel support seems to
be around release 2.6. This commit eliminates any such
support for really old 2.4 and 2.5 kernels within top.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adapts top to exploit the new <proc/pids.h>
interface. And it appears to have reduced top's weight
by a considerable margin. Gone were the sort callbacks
and manipulation of those library flags. Gosh, all top
needs to do now is track some enumerators of interest.
[ whoa, wait just a damn minute. it now appears some ]
[ that weight loss was solely the result of a theft. ]
[ jeeze, we turn our back for just a minute & newlib ]
[ up & steals our pids hashing logic for his history ]
[ needs. oh well, i guess life's just not that fair. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
While testing a newlib interface for pids acquisitions
I encountered some unexpected results if an idiot user
(me) turns off all displayable fields. So, this commit
ensures that the PID field will be shown as a minimum.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the USED column was introduced the proc_t.vm_swap
& proc_t.resident values were added together. However,
using 'resident' required an additional PROC_FILL flag
not to mention extra conversion of pages to kibibytes.
So now we'll use an already present vm_rss value which
removes any special handling for top's derived column.
And while we're at it we'll trade some more 'resident'
field uses with that more immediately usable 'vm_rss'.
[ this commit has been adapted for the newlib branch ]
Reference(s):
commit 709785e20b
Signed-off-by: Jim Warner <james.warner@comcast.net>
Jeeze, to correct spelling on one single word (incure)
you had to go and align the entire comments paragraph?
[ well, at least there's one other minor code change ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since it's possible that euser name is not being shown
or the horizontal position had been scrolled past that
USER column, then part of those headers will be blank.
So it doesn't make sense to try and show the USER that
is associated with a process at all. Thus, this commit
simply removes the 'user' provision from both headers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When a user is taking advantage of the scroll features
it is likely a scrolled vertical position is well past
the first displayable task. That is especially true of
top's forest view ('V') mode where those early systemd
attached processes are generally not very interesting.
As such, should the idle mode toggle ('i') be employed
a distorted display is almost guaranteed because tasks
that have used some cpu, and thus should be displayed,
have already been skipped by virtue of their position.
So this patch temporarily nullifies vertical scrolling
during the period when idle tasks are not being shown.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to that text shown below the line which is
common to several commit messages, this patch contains
several minor changes with lessor impact upon the API:
. A call to procps_stat_read_jiffs() has been added to
those jiffs functions carrying the 'fill' nomenclature
to parallel like functions in some of our other files.
. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.
. Standard copyright boilerplate was added in .c file.
. The header file follows the conventions of indenting
(by 4 spaces) those parameters too lengthy for 1 line.
------------------------------------------------------
. The former 'chains' have now become 'stacks' without
the 'next' pointer in each result struct. The pointers
initially seemed to offer some flexibility with memory
allocations and benefits for the library access logic.
However, user access was always via displacement and a
a statically allocated chain was cumbersome to define.
. An enumerator ending in '_noop' will no longer serve
as a fencepost delimiter. Rather, it has become a much
more important and flexible user oriented tool. Adding
one or more such 'items' in any items list passed into
the library becomes the means of extending the 'stack'
to also include user (not just library) data. Any such
data is guaranteed to never be altered by the library.
. Anticipating PID support, where many different types
must be represented in a result structure, we'll adopt
a common naming standard. And, while not every results
structure currently needs to reflect disparate types a
union will be employed so the same dot qualifier ('.')
can be used consistently when accessing all such data.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to that text shown below the line which is
common to several commit messages, this patch contains
the following additional change without an API impact:
. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.
------------------------------------------------------
. The former 'chains' have now become 'stacks' without
the 'next' pointer in each result struct. The pointers
initially seemed to offer some flexibility with memory
allocations and benefits for the library access logic.
However, user access was always via displacement and a
a statically allocated chain was cumbersome to define.
. An enumerator ending in '_noop' will no longer serve
as a fencepost delimiter. Rather, it has become a much
more important and flexible user oriented tool. Adding
one or more such 'items' in any items list passed into
the library becomes the means of extending the 'stack'
to also include user (not just library) data. Any such
data is guaranteed to never be altered by the library.
. Anticipating PID support, where many different types
must be represented in a result structure, we'll adopt
a common naming standard. And, while not every results
structure currently needs to reflect disparate types a
union will be employed so the same dot qualifier ('.')
can be used consistently when accessing all such data.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit msg summary says it all (well, not really).
The previous statically allocated results chain served
the top program perfectly in all its lib memory needs.
But, someone needs to try out the brand new interface.
Besides, there were a few other changes which I wanted
to make. And among them were the following miscellany:
. some names were changed, like 'context' became 'ctx'
. an unnecessary redundant library call was eliminated
. the placement of a few globals was made more logical
( thanks Craig for following the capitalization rule )
Signed-off-by: Jim Warner <james.warner@comcast.net>
This is actually a systemcall getpagesize(2) or it is defined
in configure using a variety of methods, including a default
hard coded value as a last resort.
There is no need to have this in libprocps
Now that the dust is settling following an initial API
library effort, it is apparent my naming standards may
not have always been observed. This was a minor crime,
since those standards are unwritten (& not apparent?).
Basically, top has always capitalized the first letter
of global variables in an effort to distinguish global
definitions from local variables later in the program.
So this patch alters the new API variables to conform,
while also explicitly using 'context' for key structs.
Lastly, top now employs the new '#include <proc/name>'
conventions for the new/converted module header files.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The new library meminfo & vmstat modules use structure
names for their context which exactly mirror the names
of the very /proc/ files whose particulars they yield.
The one exception to this rule was the readstat module
whose struct was named statinfo yet the file was stat.
This commit simply renames that structure (only) so as
to hopefully establish such a naming convention as our
standard going forward. And, it's makes good symmetry.
[ this module's name itself is just perfect as it is ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier attempt at protecting these functions from
already freed memory worked just fine until the memory
was, in fact, reused by the OS. At that point, the ref
count would most likely fail an existing a test for 0.
So this commit will take control of the 'info' pointer
and force it to NULL when a reference count reaches 0.
Plus, since it makes little sense returning an address
that a caller already has, henceforth we will return a
reference count out of the 'ref' and 'unref functions.
Reference(s):
commit 74beff80ff
Signed-off-by: Jim Warner <james.warner@comcast.net>
Procps library previously held functions that were about either
listing or finding signal names. These are not really the right
location for a library about reading procfs.
This patch handles signal related functions in two ways:
For functions purely found in skill, these have been moved back
into this binary as they are used nowhere else.
For functions used across the binaries, these have been moved
into include/signals.h and lib/signals.c. Besides formatting,
these functions are largely the same.
To assist the skill functions, two functions to access the
signal map array have been added to lib/signals.c
This commit is mostly about eliminating code, now that
a library is responsible for the cpu tics maintenance.
The top program will continue to provide numa support,
without involving the library in any of those details.
[ not to mention all the 'dl' and 'stderr' numa crap ]
With this transfer of the cpu tics duty to our library
the provision associated with the CPU_ZEROTICS #define
could not initially be migrated. The commit referenced
below suggests it may have lost its importance. In any
case such logic may yet be incorporated in the future.
But for now, that #define has been completely removed.
Reference(s):
commit ee3ed4b45e
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit represents the pioneering attempt at using
the concept of 'chained' library requests in an effort
to reduce function call overhead. It required exposing
no more implementation details than were already shown
through the individual calls, yet is satisfied in one.
It is just such an approach that will prove invaluable
when it comes time to access individual /proc/##/data.
Programs could 'chain' only those 'results' structures
representing their current view independent of all the
fields any such programs might be prepared to display.
Thus the standard 'read', which wouldn't apply to task
level data very well (or efficiently), can now become
a 'read_chain' whereby the former PROC_FILL flags need
can be satisfied & yield the minimum open/close calls.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Removed the printf_uptime, binaries can do printf easily enough.
sprint_uptime split into two as there wasn't a lot of common
code
sprint_uptime(): old style uptime line
sprint_uptime_short(): short new style "uptime -p"
Hertz_hack needed this, no sane system uses the code (I think)
so just assume 100 like we do in FreeBSD.
With the commit referenced below, the linux version is
no longer available via an external variable. So we'll
eliminate the extra superficial function call employed
at program end as part of a debugging (only) o/p spew.
[ the user will soon be returned to the command line ]
[ & he/she can run their own 'uname -r' if in doubt! ]
Reference(s):
commit 56d9d5e7e7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Added function procps_linux_version() which used to be an
exported integer instead. Also changed the method of obtaining
the linux version (more correctly the os release) to use a specific
procfs entry. This works for both Linux and FreeBSD.
This patch will bring three of our man pages into line
with the recent refactor of the libprocps wchan logic.
[ and also eliminates more damn eol whitespace which ]
[ snuck in our repo with the commit referenced below ]
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
commit cf4788c28d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch was made necessary by those library changes
in support of recently revised/simplified wchan logic.
Reference(s):
http://www.freelists.org/post/procps/WCHAN,11
Signed-off-by: Jim Warner <james.warner@comcast.net>
It doesn't make any sense to have the binary version strings
embedded into the library. The version strings are defined
already either in the Makefile or in include/c.h
[ in addition to the primary 'lxc' business, i found ]
[ numerous apostrophes used instead of that back-tic ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This will be required for subdir-objects, otherwise automake will have
problems with more than one Makefile.am having rules to build the same
files.
Tested that it builds and both `make check` and `make distcheck` work.
Tested `make install` and compared the tree with the one installed
before this commit, both installed the binaries to the same locations.
The binaries are also in the same location in the build tree (for
instance, ps/pscommand is still there.)
Checked the binaries for the correct libraries linked into them. Binary
sizes matched before and after this change.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This is required for out-of-tree build to work, since many source files
include e.g. proc/*.h which is not under the include/ directory.
Tested that `make distcheck` starts working after this patch.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
This commit just tweaks top in the following respects:
. for alphabetic integrity, change 'INSP_hdr...' names
. eliminate the -Wsometimes-uninitialized warning that
was found under OSX Yosemite (llvm 6.0/clang-600.0.56)
. update program 'comments' reflecting copyright dates
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent commit eliminated the potential for a storage
violation with forest view mode. It occurred when some
program (erroneously?) created a lengthy forking loop.
However, the associated commit message was misleading.
The message implied that an unexpected order following
a sort on start_time was the cause of storage overruns
and a 'char' used to track nesting level only distorts
the display when it goes negative. Actually, the truth
is really just the opposite. Any start_time sort quirk
causes no harm while that 'char' can yield corruption.
Should some child end up sorted ahead of its parent by
way of an extremely unlikely shared start_time the end
result is such a child will be displayed unnested just
like init or kthreadd along with all its own children.
However, if nesting levels exceeded 255 (and became 0)
a massive array overrun could be triggered when such a
task and *all* its children were added to an array for
the second time. Exactly how much storage was violated
depended on the number of children that zeroed process
had spawned (hinted at via either SIGSEGV or SIGABRT).
The earlier commit limited nested levels to 100 so the
root cause of the storage violation was already fixed.
The potential for distorted nesting levels due to sort
on start_time would seem to remain. But it's extremely
unlikely that 2 tasks would share the same start_time.
Even so, a new #define has been introduced which makes
top impervious to the order of tasks such that a qsort
is no longer necessary (providing an init/systemd task
exists & was harvested as the first task by readproc).
It can be utilized if distorted nesting ever becomes a
real issue. But since there is a 5-10% performance hit
with that, we'll continue using start_time as default.
References(s):
commit ce70017eb1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will eliminate a very nasty bug associated
with top's forest view mode. It addresses a potential
SIGSEGV/SIGABRT that was only encountered when another
program (erroneously?) creates a lengthy forking loop.
If the growing list of nested children is sufficiently
fast such that proc_t start_time is duplicated between
children then the sort upon which top relies might not
produce the expected order. That, in turn, could cause
the forest_adds function to initially miss some child.
But that missed child would be caught by forest_create
and eventually would cause our array boundary overrun.
Such overrun occurs when some child of that originally
*missed* child is found and a duplicate add attempted.
In correcting this bug we'll also use this opportunity
to prohibit a borrowed proc_t padding byte (char) from
going negative. If the nesting level exceeded 127, the
effect was an "unnesting" with the snprintf width then
viewed as flag+width also yielding left justification.
Henceforth, we'll limit nesting to 100 with subsequent
children shown as " + ", not the usual " `- " prefix.
References(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1153642http://www.freelists.org/post/procps/Bug-in-the-forrest-view,6
Signed-off-by: Jim Warner <james.warner@comcast.net>
When startup defaults were changed users with existing
rcfiles would likely find their previous configuration
was not being honored in all respects. The disparities
involved Graphs modes and Summary/Task memory scaling.
This patch simply restores what was always intended as
the proper behavior for previously saved config files.
References(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762928https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762947
. new startup defaults
commit 8ef6cd91fc
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will cure a potential aberration associated
with a terminal's size (SIGWINCH) and top's new graphs
modes. The symptoms were a dangling tilde (~) plus the
potential loss of a graph's right-most visual content.
The condition was only apparent when a %Cpu approached
100% usage. Also the apparent loss of content affected
the 'block' graph only. With 'bar' graphs, that affect
became the loss of proper right-most bar graph colors.
The cause was determined to be a combination of: 1) an
unnecessary snprintf precision specification; and 2) a
rounding quirk for any graphs which displayed distinct
types of information (as for user/syst, used/unavail).
These could then combine to produce an extra bar/block
which, in turn, resulted in the truncation of a pseudo
termcap attribute used by the show_special() function.
What was originally interpreted as an intractable race
condition turns out to be just a self inflicted wound.
Reference(s):
http://www.freelists.org/post/procps/top-Possible-bug-in-the-graphs,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
Let's not report zero for kb_main_available when older
kernels don't have MemAvailable. Instead, if we simply
duplicate the 'free' amount we can avoid all ancillary
problems, such as those involving top's graphing mode.
Reference(s):
http://www.freelists.org/post/procps/kb-main-available-etc,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch will trade a former pessimistic calculation
of free physical memory for a more optimistic one that
uses the newly added kb_main_available library export.
But in case one might wish to return to the old former
method, there's a new #define that was made available.
[ the new calculation will affect graphing mode only ]
Reference(s):
http://www.freelists.org/post/procps/systemd-support-to-library,9
Signed-off-by: Jim Warner <james.warner@comcast.net>
Might as well use the newly exposed sysinfo.h variable
'page_bytes' rather than our own. Plus, in the process
we can avoid incurring yet one more function call hit.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Gosh, just because most of us might run with some swap
file allocated, not every system might. I only wish my
testing methodology was as sophisticated as Jaromir's.
Reference(s):
http://www.freelists.org/post/procps/latest-top-enhancements,7
Signed-off-by: Jim Warner <james.warner@comcast.net>
Wow, even the linux/Documentation/filesystems/proc.txt
document doesn't provide us with that level of detail.
Thank you, Jaromir, for your additional clarification!
Reference(s):
commit 411d218793
Signed-off-by: Jim Warner <james.warner@comcast.net>
This should be the last of this kind of crap. I'll get
to work on some means to no longer burden a translator
with lengths requirements. Ideally each word should be
allowed to stand alone and the minimum/maximum lengths
handled programmatically when our ol' top is executed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For over a decade top has used a startup configuration
mimicking the original redhat top. This decision dates
back to when the forked Sourceforge version was trying
to win over users in battles with that ancient kludge.
Will anybody deny that those defaults are coyote ugly?
Well, it is time that top presented a more modern look
at startup, providing that no saved rcfile exists. But
just in case some distro prefers that old, comfortable
look, there's the '--disable-modern-top' build option.
[ Pssst. With the widened memory fields it turns out ]
[ the 'Mem' default window had become almost useless ]
[ on an 80x24 terminal since %CPU & COMMAND were out ]
[ of view. So some other defaults were tweaked a bit ]
[ whether or not --disable-modern-top was specified. ]
Reference(s)
http://www.freelists.org/post/procps/tops-graph-mode-saga-continues,3
Signed-off-by: Jim Warner <james.warner@comcast.net>
When startup argument parsing was recently enhanced to
account for LC_NUMERIC settings, some user input logic
dealing with numbers fails to exploit that capability.
This patch extends such enhancements to a running top.
Reference(s):
commit f7b84f45c7http://www.freelists.org/post/procps/topwatch-floating-point-input,2
Signed-off-by: Jim Warner <james.warner@comcast.net>
When those new cpu/memory graphs modes were introduced
they had global impact. In other words, the modes that
were chosen for a 'current' window affect Summary Area
appearance for every other window as well, even though
each window sets unique View_STATES/View_MEMORY flags.
I do not know how widespread the use of top's separate
window provisions is, but I do know that documentation
promises every window (field group) provides "a unique
separately configurable summary area". And even though
that promise does not include memory scaling (separate
'E' command) the graph modes are integral to 't' & 'm'
and those were already observed on a per window basis.
So this patch just takes the cpu and memory graph mode
values out of global scope in the configuration file &
gives each window its own unique pair of graph values.
Reference(s):
commit 1d171ec741
Signed-off-by: Jim Warner <james.warner@comcast.net>
Boy I hate locale stuff. For code I thought was pretty
robust, Jaromir sure proved that it wasn't. Anyway, me
thinks this commit closes some gaps and will cause top
to behave appropriately under various locale settings.
It does *not* permit top to respond to the ',' and '.'
floating point separator without regard to the locale.
It does, however, enforce proper LC_NUMERIC responses.
Let's look on this commit as an interim solution until
Jaromir can create that proposed 'fp_decode' function.
Who knows, he might even borrow some of our mkfloat().
[ An aside: the coreutils sleep and timeout programs ]
[ claim to permit floating point arguments. However, ]
[ neither one will accept the comma separator should ]
[ the locale be a country that in fact uses a comma. ]
[ In other words, with this commit we are way ahead! ]
Reference(s):
http://www.freelists.org/post/procps/topwatch-floating-point-inputhttp://www.freelists.org/post/procps/topwatch-floating-point-input,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
While there was no harm done setting a handler for the
above two signals, they are in fact uncatchable. Thus,
whenever we ran with valgrind we're politely reminded.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the beginning of the Mem/Swap graphs was variable
scaling them to the current terminal's width was a bit
of a costly nightmare. So the graph size was fixed and
subject to truncation. However now that the start of a
graph can be easily predicted, I've revisited scaling.
As it turns out, any cost is minimal & mostly incurred
at an opportune time, at SIGWINCH or user interaction.
Plus, most of the apparent arithmetic is actually just
a means of documenting and will disappear thru compile
time constants in the ultimate generated machine code.
Note: those graphs will now behave just like any other
Summary Area element - they will scale from full sized
down to a terminal width of 80 columns, at which point
those displayed graphs are then subject to truncation.
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the 'b' toggle remains window based (vs. global)
it should no longer require that the window be visible
and either the 'x' or 'y' toggles to be on. Previously
those requirements were intended to remind a user that
there must be something for this command to highlight.
With the introduction of graph modes (specifically the
the bar graph) the 'bold/reverse' toggle has important
implications beyond highlighting some columns or rows.
The %Cpu(s) graph and Mem portion of the memory graphs
are designed to offer a visual clue as to the separate
elements comprising them. But that separation could be
lost under some X color schemes or when top is running
without color (in monochrome mode) and the block graph
is selected. But, if the graph is then changed to bars
any separation always becomes visible whenever the 'b'
toggle is turned off. Portions then show in 'reverse'.
So from now on we'll check nothing, we'll just toggle.
[ Besides, with all the code thrown at restricting a ]
[ 'b' toggle use, it might have all been for naught. ]
[ That toggle could still be set/unset using the 'Z' ]
[ command and the color mapping screen. Geez Louise! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just beefs up the man documentation for the
new graphs modes while also reflecting the most recent
program changes, prompted by the feedback shown below.
Reference(s):
http://www.freelists.org/post/procps/latest-top-enhancements,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
My original graph modes implementation made no attempt
to align the Cpu & Mem/Swap graphs. I thought, rather,
that such alignment could be best achieved by the user
using top's 'E' memory scaling command toggle. In that
way Mem/Swap prefixes could be reduced by 3 positions,
bringing the beginning '[' into line with the %Cpu(s).
If that proved to be too cumbersome a #define could be
enabled making the Mem/Swap prefix static while adding
a few padding bytes to the %Cpu line(s) for alignment.
It was those waisted bytes that were the most concern.
What I had not counted on was the fact that the memory
lines themselves might become misaligned & that became
likely with more physical memory present. That too can
be cured with the 'E' command but as scaling is raised
we soon reach a meaningless total such as '0.003' even
though the displayed % remains valid (and unchanging).
So this commit implements unconditionally what used to
be conditional. But, instead of waisting padding bytes
we'll put that space to good use with a new 'total %'.
Reference(s):
http://www.freelists.org/post/procps/latest-top-enhancements,1
commit 1d171ec741
Signed-off-by: Jim Warner <james.warner@comcast.net>
My first blush graphs modes implementation went just a
tad overboard on identifier lengths. As a result, some
program lines were getting quite long. So, this commit
will simply shorten some excessively long identifiers.
Reference(s):
http://www.freelists.org/post/procps/latest-top-enhancements
commit 1d171ec741
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch makes 't' (View_STATES) & 'm' (View_MEMORY)
commands into 4-way toggles. The two new modes provide
for two different graphs of the cpu and/or memory use.
These new capabilities are similar to those offered by
the 'htop' program. However they're aesthetically more
pleasing (to me) plus the scalings are more authentic.
Poor ol' top has long been troubled by the comparisons
offered up by the 'htop' program. Many of those things
were only true of the original redhat top while others
are no longer true of this current top program. So let
me use this commit msg to begin to correct the record.
Corrected comparisons between 'htop' & 'top' programs:
------------------------------------------------------
+ htop does not start faster, actually reverse is true
+ top offers scrolling vertically and horizontally too
. (and top offers better <Home> and <End> key support)
+ unassigned keystrokes don't subject top to any delay
. (but htop suffers that annoying ncurses <Esc> delay)
+ in top one need not type the PID to kill the process
+ in top one need not type the PID to renice a process
Some things the 'htop' program was not bragging about:
------------------------------------------------------
+ top can outperform the htop program by a wide margin
+ htop + SIGWINCH = corrupted display + restart likely
+ htop cannot preserve its screen data at suspend/exit
+ the htop column management scheme is very cumbersome
+ htop allows columns to be duplicated again and again
+ htop displays only full command lines, not pgm names
. (and that 'Command' column must always be displayed)
. (and it must always remain as the last column shown)
+ htop does not provide for any sort of command recall
+ htop's search feature does not highlight any matches
+ there is no 'find next' outside of htop search modes
+ htop does not allow Header or Process memory scaling
+ htop provides no flexibility on column justification
+ htop does not provide the means to change col widths
+ htop provides less control over colors configuration
+ htop always overwrites the rcfile with any UI change
Someday, maybe we'll provide a better comparison as an
addendum for (or replacement of) that README.top file.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In anticipation of upcoming memory graphing provisions
the abbreviations 'Mem' and 'Swap' are being made into
individual translatable strings in order to be reused.
Additionally, the Mem 'used' amount will now no longer
included the 'buffers' and 'cached' values. Thus, each
Mem category becomes unique. This is the approach used
by tools such as 'htop' or the gnome 'System Monitor'.
Lastly, with that change to the 'used' category it has
been repositioned after 'free' on the Mem & Swap lines
making a comparison between 'total' and 'free' easier.
Signed-off-by: Jim Warner <james.warner@comcast.net>
For some time now, top has refrained from updating the
current number of cpus and memory totals with each and
every refresh cycle. Rather, to lessen overhead costs,
such values are updated periodically (5 min & 3 secs).
The delay in updating the cpu count was only important
with the addition of a cpu, since any loss is detected
immediately. And the large interval was chosen because
of the costs once associated with a glibc sysconf call
and an unlikely scenario of physically adding the cpu.
But the ease with which cpus can be taken offline then
placed back online under linux suggests that 5 minutes
may be too high. So, without addressing the likelihood
of that act, top is now more responsive in these ways:
1) that 5 minute interval has been reduced to 1 minute
2) any key, not just Enter/Space, refreshes cpus & mem
Note: we leave the man document as is, suggesting that
only the Enter/Space keys force an update for hotplug.
Signed-off-by: Jim Warner <james.warner@comcast.net>
. prevent any input recall overrun if window downsized
. adjust translation notes for true column hdr maximum
Signed-off-by: Jim Warner <james.warner@comcast.net>
In release 3.3.6, some commands were equipped with the
concept of a 'default pid'. The initial implementation
meant that the intuitive <Esc> key would not always be
treated as one would expect under any well behaved UI.
This patch ensures the expected <Esc> key behavior of:
terminating user input while still making possible the
necessary distinction between 'no input' & 'defaults'.
Reference(s):
http://www.freelists.org/post/procps/top-Escape-doesnt-abort-kill-command
Signed-off-by: Jim Warner <james.warner@comcast.net>
The granularity of /proc/uptime is fixed at hundredths
of a second. And, since we can cycle faster than that,
we are exposed to 'nan' when calculating elapsed time.
This commit will protect us from that outcome when the
delay interval has been set to an extremely low value.
Signed-off-by: Jim Warner <james.warner@comcast.net>
In addition to eliminating numerous single quote usage
this commit also escaped '\' a few overlooked hyphens.
And some 'unformatted' spacings were adjusted as well.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The majority of changes in this commit are intended to
enable translation of top's man page. There were three
kinds of errors as seen by that po4a-updatepo program.
. a valid but unrecognized request concerning no-break
. an internally defined macro with a groff .de request
. occasional apostrophe at the beginning of some lines
With respect to the apostrophe, some have been changed
to back-tic since line placement could not be assured.
And other parts were re-flowed to avoid temptations to
escape as \' (technically an acute accent). Of course,
the opening back-tic with closing apostrophe looks odd
when ASCII, but should be rendered correctly as UTF-8.
It may yet be necessary to change the remaining single
'opening' quotes to back-tics as translation proceeds.
Should that become necessary, I intend to reduce quote
usage to the bare minimum throughout the man document.
There were also some formatting changes to enhance the
man2html output and then to other formats via htmldoc.
And, I wish to acknowledge that my meager groff skills
do not serve those programs very well at all. In other
words groff yet remains mostly incomprehensible to me.
Lastly a few content plus copyright updates were made.
Message(s):
. Unknown macro '.c2 `'. Remove it from the document, or refer to the Locale::Po4a::Man manpage to see how po4a can handle new macros.
. This page defines a new macro with '.de'. Since po4a is not a real groff parser, this is not supported.
. Unknown macro ''real time' scheduling priority.'. Remove it from the document, or refer to the Locale::Po4a::Man manpage to see how po4a can handle new macros.
Reference(s):
. oriiginal post/patch
http://www.freelists.org/post/procps/Translations-for-man-pages
Signed-off-by: Jim Warner <james.warner@comcast.net>
If a system's time is adjusted backwards, then elapsed
time could appear as negative. This yielded a negative
%CPU value. Alternately if zeros were suppressed ('0')
the result was a blank %CPU column. In both cases that
distortion would last for one display cycle or until a
user forced a display refresh via some keyboard input.
The original recommendation was trading gettimeofday()
for clock_gettime() using CLOCK_MONOTONIC. But on some
systems that might not be possible, forcing the use of
CLOCK_REALTIME instead. Not only would that complicate
the build system, but it may leave us with minus %CPU.
Another approach was to ensure that elapsed time could
never be negative. Of course, this produced distortion
of %CPU values but it would be proportionally correct.
This wasn't dissimilar to a distortion already present
should the time be adjusted forward or backward within
any 'remaining' top delay intervals. These aberrations
would be avoided with clock_gettime & CLOCK_MONOTONIC,
but that is a less than ideal solution as noted above.
This final solution, which originated down under, will
simply rely on the /proc/uptime seconds, which will be
immune to *any* tampering with the system clock. Thus,
we now have a fix for the distortion we didn't know we
suffered plus a negative %CPU that began this odyssey.
Thanks to:
sk.alvin.x@gmail.com, for the original effort
jcapik@redhat.com, for a heads up on CLOCK_MONOTONIC
csmall-procps@enc.com.au, for the best suggestion of all
Reference(s):
. original post/patch
http://www.freelists.org/post/procps/PATCH-top-use-clock-gettime-instead-of-gettimeofday
. heads up on CLOCK_MONOTONIC
http://www.freelists.org/post/procps/PATCH-top-use-clock-gettime-instead-of-gettimeofday,2
. the final solution
http://www.freelists.org/post/procps/PATCH-top-use-clock-gettime-instead-of-gettimeofday,11
Signed-off-by: Jim Warner <james.warner@comcast.net>
Minor fixes that the translator (Yuri) has found in some of the
strings. You only know how many typos and thinkos you have when
someone is trying to translate it.
Signed-off-by: Craig Small <csmall@enc.com.au>
Since its inception top has always used enumerators to
identify displayable fields. They've taken the form of
P_PID, etc. As it turns out, something has changed for
libc6-dev versions beyond 2.17-93 wherein 'P_PID' will
now be exposed via stdlib.h. I have not pinpointed the
exact cause but it may depend on header include order.
This patch just trades top's long standing 'P_' prefix
convention for that of 'EU_' (short for enumerator). I
cannot find *any* header under /usr/include/ currently
utilizing this particular three character combination.
And as a further safeguard top will henceforth include
'system' specific headers after the standard includes.
Reference(s):
http://www.freelists.org/post/procps/top-wont-compile-anymore
Signed-off-by: Jim Warner <james.warner@comcast.net>
When top originally responded to the potential libnuma
stderr write, the library was consistently called with
each refresh cycle. That, in turn, guaranteed that any
warning message would be seen at program end by virtue
of: 1) having been issued before the 2nd refresh cycle
and; 2) benefiting from inherited /dev/null buffering.
A later efficiency refactor meant the numa library may
not always be called with every refresh cycle. Rather,
it was only called if top was in one of two numa views
(the '2' or '3' toggles). That, in turn, resulted in a
loss of any warning message at program end unless numa
mode had been preserved in the rcfile. In other words,
if top was started normally then a single cycle stderr
redirect would have long passed by the time the '2' or
'3' toggle was activated. The warning message actually
was spewed but quickly lost to the full screen refresh
which follows all keyboard interactions with the user.
This commit simply moves the restoration of our stderr
redirect to program end (instead of that first display
refresh). Now, any libnuma stderr warning message will
appear as the concluding output line upon quitting top
without regard to when any numa mode view was invoked.
And since this technique might be useful in some other
context (as an example of how to 'buffer' stderr) it's
been generalized with its own #define. But to maximize
its usefulness, the original redirect should be issued
much earlier in pgm startup than top has chosen to do.
Reference(s):
. original libnuma stderr response (msg seen)
commit 35dc6dcc49
. numa refractoring for efficiency (msg lost)
commit f12c0d5c6e
Signed-off-by: Jim Warner <james.warner@comcast.net>
Apparently there are occasions when NUMA nodes may not
always be contiguous. Under such conditions nodes that
were not used would still occupy precious Summary Area
space showing 100% idle, under the '2' command toggle.
With this commit top will no longer display numa nodes
that have no associated cpu when the '2' toggle is on.
But just in case we wish to return to former behavior,
a new #define called OFF_NUMASKIP has been introduced.
And as an aside, a recent refactor mentioned below set
the stage for this patch to be 'self-tuning'. In other
words, if an inactive/non-displayed node should become
active (if even possible), then top will begin showing
such a node automatically with the next screen update.
Unfortunately, all inactive nodes now 'suppressed' are
still accessible via the '3' command. Those nodes will
just be displayed as empty (no associated cpus shown).
This is not really a top problem but more of a libnuma
and/or user deficiency. The library lacks the means to
validate a node id and the user then input a node that
was not even shown under a '2' toggle Summary display.
( too bad libnuma does not offer an 'is_node_active' )
( type function so top could warn a user when such a )
( discontinuous node was requested using his '3' cmd )
( sure, top could achieve this objective himself but )
( that would require making yet another array global )
( which i'm just not in the mood to do - besides, we )
( have already made enough concessions to libnuma.so )
Lastly, an existing #define (PRETEND_NUMA) was changed
to 'disable' node #1 so as to simulate a discontinuous
node. This allows testing of the '2' and '3' commands.
Reference(s):
http://www.spinics.net/lists/util-linux-ng/msg08671.html
. set stage for self tuning
commit f12c0d5c6e
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent change involving a one cycle stderr redirect,
to handle a libnuma potential transgression, failed to
follow normal global variable naming conventions. This
patch will capitalize the 1st letter of 'Stderr_save'.
Reference(s):
commit 35dc6dcc49
Signed-off-by: Jim Warner <james.warner@comcast.net>
Excluding those special X_XON/X_XOF enums, which might
not even be present, restore strict collating order of
all the case labels in the task_show switch statement.
Also, adjust a few sort callbacks for the same reason.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The recent addition of namespaces, combined with those
potential suse out-of-memory fields, means that we are
close to the maximum number of fields poor ol' top can
display. Imagine, the really old top was limited to 26
fields (28 with the suse hack) and this top had neared
the version 'g' rcfile limits which were a healthy 55.
This patch adds another 15 fields to the maximum while
making it even easier to increase in the future. Also,
top still silently accommodates older config files all
the way back to the original pre-ng version top-3.2.8!
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is inspired by the 'minimize numa overhead'
patch. It trades the use of subscripts for pointers to
avoid gcc repeated subscript offset calculation bloat.
Now, throughout the cpus_refresh function, a subscript
will be resolved just once & this will (dramatically?)
reduce the path-length taken for each and every frame!
For example, a non-optimized compilation could produce
400+ fewer machine instructions through pointer usage.
[ ok, optimized compiles only save 18+ instructions! ]
Lastly, any residual 'symmetry only' crap is now gone!
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent libnuma potential corruption problem solution
has caused me to reevaluate some associated numa logic
for efficiency. Here is a summary of the problems that
exist with current libnuma/user possible interactions:
. Whenever the numa library was present extra overhead
would always be incurred in maintaining the node stats
even when the '2' or '3' commands were not being used.
. As part of such overhead a separate loop was used to
reinitialize each cpu/node structure with each display
cycle so that prior accumulated totals were preserved.
Again, it didn't matter if numa data was really shown.
This commit attempts to refocus on the 'critical path'
costs in a running top by optimizing for the occasions
when numa node data is not being displayed. Under such
conditions, no extra overhead will be incurred whether
or not a distribution has the libnuma library present.
To achieve this goal, some additional overhead will be
incurred, but only when actually displaying numa data.
And all such new costs have been minimized in spite of
the gcc inclination to duplicate subscript resolution.
Reference(s):
commit 24bd950cb2e1722d459461f0f9c0c30a4b9ffdaa
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent libnuma potential corruption problem solution
suggests that libnuma could change in the future so as
to not spew to stderr. This then raises a question how
top could exploit any such library change since we are
currently locked into version #1 of the library by way
of our dlopen("libnuma.so.1", RTLD_LAZY) runtime call.
While not an ultimate solution, this commit will first
try for the most recent version of that library during
top's startup before trying the original libnuma.so.1.
We do this via the unqualified library soname symlink.
For this new dlopen() call to succeed, technically the
numa 'devel' package would usually have been required,
but that's not always true with every distro. And when
the libnuma.so symlink isn't present, it can always be
manually added should a newer & better behaved library
arrive & users tire of the stderr warning at top exit.
Reference(s):
commit 24bd950cb2e1722d459461f0f9c0c30a4b9ffdaa
Signed-off-by: Jim Warner <james.warner@comcast.net>
Confession is supposed to be good for the sole, right?
After a senior moment regarding the 'x' toggle quirks,
and thinking top had somehow regressed, I concluded an
additional explanatory note might well be appropriate.
Those quirks were already documented under the 5d & 5e
topics. But there was no such caution documented under
the 'x' command explanation itself, found in topic 4c.
Signed-off-by: Jim Warner <james.warner@comcast.net>
There is a chance that the libnuma library may corrupt
top's display with some stderr warning messages in the
event something under /sys/devices/system/node/ cannot
be accessed. And, while 2 overridable 'weak' functions
are provided to alter such behavior, we can't use them
since top dynamically links to the library via dlopen.
This commit will redirect stderr to '/dev/null' during
just the first screen display cycle. Thus we can avoid
the corruption which would have remained visible until
the underlining screen row's data had finally changed.
Lastly, this patch should allow such a library warning
to actually appear when one finally exits our program.
[ i think the libnuma folks should consider changing ]
[ the error/warning interfaces to accommodate dlopen ]
[ rather than forcing something like the ugly kludge ]
[ we have employed or libnuma dependency on everyone ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=998678
Signed-off-by: Jim Warner <james.warner@comcast.net>
When Other filtering was introduced the nature of what
constituted a displayed row changed. No longer would a
task_show() call guarantee that another line is shown.
Rather, a non-empty string must have also been tested.
Unfortunately, when any task window was being filtered
for 'idle' mode or a particular 'user', the proc index
was incremented twice due to the perils of copy/paste.
Combining such an index increment with the new test of
task_show results works fine if filtering is inactive.
This was a particularly insidious bug which meant that
an adjacent task would be skipped whenever the current
task met 'idle' and/or 'user' filter criteria, and was
not otherwise excluded due to 'Other' filter criteria.
And, since it was the very next task that was ignored,
the bug was very susceptible to a window's sort order.
This could be illustrated when filtering on some user,
while sorting on PID. Then, toggling Forest View could
make otherwise unseen tasks appear and then disappear.
User workarounds are possible via interactive commands
trading the 'i' and 'u'/'U' provisions for the 'o'/'O'
other filtering capability thus avoiding an extra i++.
But that is certainly less than ideal and doesn't help
the 3.3.7 and 3.3.8 distorted command line provisions.
( this little buggie may end up costing me my pocket )
( protector, my coding badge & maybe even my cubicle )
Reference(s):
http://www.freelists.org/post/procps/Idle-elides-nonidle-processes
. bug originated with 'Other' filtering
commit 5edc6fb317
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adds the final newline when exiting 'Batch'
mode. Interestingly, it has been missing since release
3.3.5 but undetected until the Redhat bugzilla report.
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1008674
Signed-off-by: Jim Warner <james.warner@comcast.net>
Normally, the internally tracked 'Screen_cols' can not
exceed the lessor of 512 or actual screen width. There
was one case, however, where that 512 byte upper limit
was no longer properly imposed as it should have been.
When operating in 'Batch' mode the actual screen width
was allowed to be exceeded when the optional -w switch
was also used. But, it should never have exceeded 512.
This patch ensures the upper limit is always observed.
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721204
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch addresses the four '-Wunused-result' errors
generated whenever an optimized compile is invoked. It
also made the configs_read() guy a little more robust.
In the process, some logic was rearranged slightly and
some comments were re-indented simply for consistency.
Reference(s):
warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the final solution for cursor positioning for all
^Z or ^C cases was introduced the revised placement of
message line management introduced with the window mgr
'screen' refactor was retained. Those two commits mean
that a former tgoto was no longer needed when clearing
that msg line or displaying the scroll coordinate msg.
This patch eliminates the tgoto employed by frame_make
while assimilating a now defunct show_scroll function.
Reference(s):
. final cursor positioning for ^Z or ^C
commit 46a1356219
. 'screen' window manager refactor
commit 0fe393ff27
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just provides a visual clue to separate the
values reported for cached Memory from other values on
the Swapped line (which is being shared due to space).
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718670
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some more (very obscure) conditions where a suspension
or program end might embed the shell prompt within top
output have been uncovered beyond the 2 already known.
We had already covered some suspend/end contingencies:
1. the users were using the 'fields management' screen
2. the users were prompted for any line oriented input
However, there remained some situations where ^Z or ^C
could still produce a misplaced cursor + shell prompt:
3. the 'g' command while waiting for the window choice
4. the 'W' command if about to overwrite an old rcfile
5. the '=' command when exploiting the Inspect feature
6. the period during which any error message was shown
But, even when all those bases are covered there still
remains a remote possibility that such interrupts will
occur during a top repaint cycle. So rather than throw
yet more code at these self-inflicted problems perhaps
it is better if we just throw in the proverbial towel.
Thus, I'll take the only sane approach and restore the
results expected ever since top's inception and before
scrollback buffers entered the picture. Namely, with a
^Z or ^C the cursor will be placed on the final screen
row. That usually means it will immediately follow the
last output line but it may follow many blank lines if
the user interrupts top when *not* on the main screen.
Reference(s):
. expanded repositioning (for line oriented input)
commit 33104a2bcc
. introduced repositioning (for fields management)
commit 5c974ff44d
. scrollback buffers (the cursor handling changes)
commit dedaf6e1a8
Signed-off-by: Jim Warner <james.warner@comcast.net>
An obscure bug has been discovered where a 'W' with an
old rcfile, warning against overwrite, would display a
cursor that should normally be hidden. This followed a
user's reply. So some logic was rearranged just a bit.
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent patch introduced the ability to recognize the
need to reposition the cursor at suspension or program
end. There remained unmet 1 additional potential need.
This commit extends that ability to embrace line input
so that if a user issues ^Z or ^C while being prompted
the resulting shell output will no longer be embedded.
Reference(s):
http://www.freelists.org/post/procps/top-library-miscellaneous-tweaks,7
commit 5c974ff44d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit mostly justs renames a few identifiers but
it also will now suppress any end-of-job report if top
wasn't ended via the 'q' key convention (i.e. signal).
Signed-off-by: Jim Warner <james.warner@comcast.net>
The title of this commit is actually quite misleading.
Were it more accurate, it would at least mention a tty
emulator's scrollback buffer, which was the cumulation
of a long pursuit to reduce the SIGWINCH overhead when
a window manager carelessly floods an application with
that signal *while* a user is still resizing a window!
Disabling and enabling that scrollback buffer resulted
in the final top display replaced with original screen
contents, a phenomenon acknowledged at the time but it
also represented a user interface change which has now
produced the first request for return to old behavior.
After the SIGWINCH dust settled, another problem arose
regarding behaviors under the 'screen' window manager.
In response, top was refactored a bit to avoid display
corruption. That was before discovering 'screen' could
duplicate the scrollback buffer behavior top expected.
As it turns out, the 'screen' refactoring had probably
made scrollback buffer manipulation unnecessary. Still
one could argue that a window should not be allowed to
scroll while a constantly updating program was active.
The solution represented in this commit returns former
behavior at program end (retaining top's last screen).
And if we ever wish to disable scrollback buffers, the
associated logic was retained but made conditional. It
is not reflected in configure.ac but might be someday.
Lastly, this commit corrects cursor positioning when a
^C is issued under 'Fields Management' at any terminal
that didn't have a scrollback buffer (i.e. a console).
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=977561http://www.freelists.org/post/procps/top-library-miscellaneous-tweaks,1
. screen program refactor
commit 0fe393ff27
. scrollback buffer disabled
commit dedaf6e1a8
. sigwinch management defines
commit adca737758
commit 4f33b6b8c5
Signed-off-by: Jim Warner <james.warner@comcast.net>
The .Bd and .Ed macros, from the mdoc collection, have
caused a few raised eyebrows (lintian, doclifter, etc)
in the past. With this commit, we will trade their use
for the standard existing groff .nf & .fi equivalents.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the plug-in approach to NUMA support was added, I
carelessly employed the compile-time linker convention
for naming the library. Technically this then required
the 'devel' package for NUMA support to be present for
the unqualified soname symlink to be available. Either
that or one must have manually created such a symlink.
This commit adds the missing major version to dlopen()
of libnuma.so.1 so simply having a more likely package
such as 'numactl' will enable both '2' & '3' commands.
References(s):
http://www.freelists.org/post/procps/top-NUMA-node-CPU-utilization-support,25
. initial dlopen support
commit edba932a7e
Signed-off-by: Jim Warner <james.warner@comcast.net>
If top were invoked under the 'screen' window manager,
writing the terminfo string 'exit_ca_mode' at top exit
would not restore the display to the state existing at
the time top was started. That's what occurs normally.
The net result of that failure was a corrupted screen.
However, there is a 'screen' configuration option that
will produce proper 'rmcup' behavior, but it is off by
default. That screencr option is known as 'altscreen'.
I stumbled across this provision by cloning the screen
git repository then searching for references to 'cup'.
If 'altscreen on' had been in either the /etc/screenrc
or the $HOME/.screenrc configuration file, my poor old
top would never have been accused of such corruptions.
Of course, the Programming Gods decree that any simple
solution for our problem must always be revealed last.
So before discovering that rc option, another approach
was taken involving top only. With just a little extra
refactoring of top display logic he was made immune to
any such quirk in the implementation of 'smcup/rmcup'.
I always feel good about any enhancement that actually
reduces the total number of lines of code. Even though
this change involved mostly rearranging some logic, it
yielded one less line (can't judge by diffstat because
of braces & notes). Anyway, rather than requiring some
change to a screenrc file, now we are self-sufficient.
Reference(s):
procps ---------------------------------------------
https://bugzilla.redhat.com/show_bug.cgi?id=962022http://www.freelists.org/post/procps/top-procpsng337-no-screen-cleaning-at-exit,3
. top : disable tty scrollback buffer to improve SIGWINCH
commit dedaf6e1a8
screen ---------------------------------------------
git://git.sv.gnu.org/screen.git
. Improve cursor store/restore on smcup/rmcup.
commit f95352946080be803b794c9f2733d8c809c1a39a
. Fix using alternate screen buffers in some cases.
commit ad56f746c6243d45124485d198d577bdbb78071c
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558724
Signed-off-by: Jim Warner <james.warner@comcast.net>
When summary & task area memory scaling was introduced
in release 3.3.6, the memory field widths were widened
slightly so unscaled KiB values could be provided more
consistently and scaled values (beyond MiB) could show
3 decimal places of precision. However, some users may
prefer the former widths/precisions for memory fields.
This commit will provide a build time configure option
to return top to those former defaults as a compliment
to a new %CPU & %MEM field precision configure option.
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707648
commit 21e550bc08
Signed-off-by: Jim Warner <james.warner@comcast.net>
When summary & task area memory scaling was introduced
in release 3.3.6, the percentage columns were expanded
to provide 3 decimal places of precision. In hindsight
that may have been overkill, making those columns more
of a distraction than useful, with just too much info.
This patch will revert those columns to the former one
decimal place. And as was true, that decimal point may
be sacrificed depending on the number of cpus present.
And, in case anyone might prefer additional precision,
a build option can provide it (--enable-wide-percent).
Reference(s):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707648http://www.freelists.org/post/procps/What-happened-to-my-top,1
commit 21e550bc08
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some versions of man have had trouble with the leading
apostrophe employed with interactive commands/toggles.
Instead, a '?' would be displayed in their place. With
this patch all such conventions have now been removed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The earlier commit purporting to allow top to be built
in the absence of that dynamic linking library stopped
just a little short of the truth. So this will fix it.
Reference(s):
commit 5686877cd4
Signed-off-by: Jim Warner <james.warner@comcast.net>
The NUMA/Nodes support in top has gone through several
evolutions (primarily dealing with build-sys options).
With this commit the library dependency issues are now
moot and the responsibilities for run-time loading and
dynamic linking are assumed by the top program itself.
Henceforth, if top is executed in an environment where
libnuma.so is present, top will offer such extensions.
Even more importantly, when a missing libnuma is later
installed, top will offer numa support auto-magically.
All NUMA/Node build-sys dependencies are thus removed.
The former NUMA_ENABLED define has become NUMA_DISABLE
should anyone wish to test user interface implications
in an environment that *does* have libnuma. It is also
represented as the ./configure option: --disable-numa.
Lastly, the 't' (View_STATES) toggle will be forced on
for sanity whenever the '1', '2' or '3' keys are used.
Reference(s):
. original idea from: Dr. Fink <werner@suse.de>
http://www.freelists.org/post/procps/top-NUMA-node-CPU-utilization-support,18
. original numa suppoort
commit 8d989c68c0
Signed-off-by: Jim Warner <james.warner@comcast.net>
Oh that poor ol' build system. With this patch it will
have gone through three separate incarnations in terms
of NUMA/Node support. Those 3 iterations consisted of:
1. A 'porridge too hot' where the top numa support was
enabled if it was built in the presence of libnuma and
the numa.h header. But if the numa library wasn't part
of core packages, that would have broken poor old top.
2. A 'porridge too cold' where numa support was off by
default and must have been explicitly enabled when the
./configure script was run. This could have meant that
distros might not distribute a numa-aware procps, even
though their numa library would have been distributed.
3. And this 'porridge' where the top numa support will
become a 'plug-in' feature activated when the presence
of libnuma.so can be verified at runtime. We'll do our
own loading and symbol resolution (with some help from
dlopen in libdl). Thus maintainers' responsibility for
enabling numa support and then satisfying that library
dependency is now an entirely optional --disable-numa.
As Goldilocks might say about our current configure.ac
"Ummm, I think this porridge tastes just about right".
Reference(s):
. 1) too-hot
commit 87ac6383bb
. 2) too-cold
commit 53fd7dd1ed
. original idea from: Dr. Fink <werner@suse.de>
http://www.freelists.org/post/procps/top-NUMA-node-CPU-utilization-support,18
Signed-off-by: Jim Warner <james.warner@comcast.net>
Almost forever, top has been accessing the /proc/stat/
directory one line at a time until either smp_num_cpus
was reached or (more recently) Screen_rows is reached.
When NUMA/Nodes support is enabled screen rows will no
longer serve as a limit because all cpus must be read.
With this commit, the entire /proc/stat/ directory can
be read at once so all statistics will be frozen. Thus
individual cpus will no longer keep "ticing" until top
gets around to accessing them via some separate fgets.
The distortion this commit eliminates was quite easily
seen when comparing old/new tops using: individual cpu
stats vs. cpu summary; a healthy delay interval of 3-5
seconds; manually synchronized update cycles (the hard
part); some system loading (maybe another top at -d0).
Additionally, this patch eliminates some long standing
unnecessary initialization made possible because of an
allocation via calloc. If some parts are never touched
by sscanf due to a kernel version, it's unnecessary to
repeatedly re-initialize those portions to zero again.
Reference(s):
. numa extensions added
commit 8d989c68c0
. useless initialization evolution (old to new)
commit e54c8239b1
commit 9278134e49
commit fd62123562
commit f348575edc
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the addition of NUMA/Node support and the ability
to emulate such support even in the absence of libnuma
and numa.h, the maximum number of cpus top can emulate
was increased to make numa emulation more interesting.
( whew, that's an awful lot of "emulates", me thinks )
Reference(s):
commit 8d989c68c0
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit extends the top Summary Area cpu states to
include information on Non-Uniform Memory Architecture
nodes. It is based upon changes originally proposed by
Lance Shelton who was instrumental in the final patch.
With this change, the user will have new commands that
will provide alternatives to the individual cpu stats:
. '2' toggles between cpu & numa node summary displays
. '3' provides node summary and related cpu statistics
These extensions required some minimal system support.
Typically, the numactl package (and maybe libnuma-dev)
are all that's needed to show a single node which owns
all the processors. Failing that, or for slightly more
variety, top also offers a #define named PRETEND_NUMA.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Lance Shelton <LShelton@fusionio.com>
This commit provides the NEWS and man document changes
supporting the new NUMA/Node top program enhancements.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Lance Shelton <LShelton@fusionio.com>
This patch provides the build system support for those
top extensions dealing with the NUMA summary displays.
For providing the initial impetus for this enhancement
I wish to thank Lance Shelton <LShelton@fusionio.com>.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Lance Shelton <LShelton@fusionio.com>
When 'Other Filtering' was introduced the idea of what
constituted a displayed row changed. No longer was any
call to task_show assured of consuming one screen row.
Now the determining factor was whether or not the rows
were empty. This worked Ok until a certain Find string
was active then the entire display could be corrupted.
With Find active, the task_show() function alters each
returned row while highlighting each visible match. If
the search was on a single byte value & matched at the
beginning of a row the match got overwritten with '\0'
which then appears empty upon return to window_show().
So that row would not be counted as having been shown.
This was best illustrated with a Find on a single ' '.
This patch will restore proper 'Find/Locate' behavior.
Reference(s):
commit 5edc6fb317
Signed-off-by: Jim Warner <james.warner@comcast.net>
If the 'Inspect' feature was used to view a file which
contained binary (unprintable) data, and when the last
line for such a file was purely unprintable, then that
line length would be overstated by the terminal width.
This was also the occasion where valgrind might object
over potential reference to some unitialized value(s).
It was a harmless situation and somewhat rare to begin
with. Anyway this commit will eliminate the potential.
Additionally, supporting readfile logic was simplified
and the 'status line' bytes read is now more accurate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some recent nls work on that pmap program necessitated
a return to nls translation file creation for testing.
As it turns out, my skills used in pseudo-translations
had become rusty and some newer LC_MESSAGE directories
may have been introduced since last needing the topic.
This patch just updates some programmer notes to agree
with this most recent effort and for future reference!
Reference(s):
. pmap nls support
commit 0c0c543466
Signed-off-by: Jim Warner <james.warner@comcast.net>
There is a member of the osel_s structure called 'flg'
that is used to reflect whether a particular filter is
one of inclusion or exclusion (negation). So by golly,
from now on we'll refer to it as 'inc', and not 'flg'!
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit involves very little content change and is
more concerned with better formatting for readability.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the command line sort override provisions (-o/-O)
were added, the usage text was modified to keep within
an 80 column terminal but the nls hint didn't keep up.
Reference(s):
commit 407d1fc8f2
Signed-off-by: Jim Warner <james.warner@comcast.net>
Two too many of these '=' (cooks) spoiled top's broth.
There exists an unintentional variation on the classic
error: off-by-one. When a negation symbol is used with
top's new relational 'other filter' provision, one too
many 'matches' are excluded. This happened because top
covered only 2 of the 3 potential strcmp return codes.
When the strings were equal, they were simply dropped.
So this patch will uninvent that particular variation!
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 2c2c5f5cd2
Signed-off-by: Jim Warner <james.warner@comcast.net>
When I originally entertained thoughts of maybe adding
relational operators to the new 'Other Filter' feature
the programming challenges seemed just too great. Yet,
when Jaromir suggests its desirability it now suddenly
becomes a reality. Another of life's little mysteries!
At any rate what was already an extremely powerful new
feature is even better by several orders of magnitude!
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
References:
http://www.freelists.org/post/procps/top-beyond-infinity,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit provides the hard copy support for our new
'Other Filter' feature. The man document contains some
potentially useful examples and it will be interesting
to see what use this new tool is put to in the future.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This change represents the extension of user filtering
based on inclusion or exclusion. However where 'U'/'u'
filtering provides an either/or choice, this extension
offers multiple choices applicable to multiple fields.
The 'inclusion' and 'exclusion' criteria can be freely
combined making a powerful tool to fine tune a display
and avoid clutter associated with uninteresting tasks.
I'm convinced it offers unimagined future flexibility!
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/top-over-the-top,22http://www.freelists.org/post/procps/top-over-the-top,8
Signed-off-by: Jim Warner <james.warner@comcast.net>
While it's only documented (so far) in commit text and
an occasional email I've tried to maintain some coding
standards primarily for reference/navigation purposes.
They also served, I felt, as useful mental challenges.
Someday I will get around to formerly documenting them
but in the meantime here are the ones for this commit:
. functions are grouped into logical (i hope) sections
. functions & sections are ordered to avoid prototypes
. function names are alphabetical within every section
Thus, given those constraints/objectives, and in order
to prepare for an upcoming Other_Filter feature, a few
things had to be renamed and rearranged. Plus a couple
of other (unrelated) tweaks were made for consistency.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 270e8e7eebhttp://www.freelists.org/post/procps/PATCH-12-top-restore-terminal-state-on-exit,4
Signed-off-by: Jim Warner <james.warner@comcast.net>
if top is suspended while on the 2nd level help screen
the <Enter> key is no longer honored. Thus, users must
use <Esc> to exit help and return to the main display.
Also, line input that was only partially complete when
suspended would still require one additional keystroke
before the read was aborted and the display refreshed.
Lastly, some user interactions might require two input
lines before an operation can be considered completed.
Thus the 2nd line offers another opportunity for users
to suspend top. Resumption would require an extra key.
These issues stem from 2 recent enhancements: preserve
the user context when signaled; complete input editing
with cursor movement keys, insert/overtype modes, etc.
With this patch, the <Enter> key is once again honored
on help screen #2 and partial reads are now completed.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
bug reported
http://www.freelists.org/post/procps/top-over-the-top,25
response to ^Z (partial solution)
commit 5c3fffcf28
line input editing
commit 477b10c0bd
preserve context with SIGWINCH
commit ba9092ad83
Signed-off-by: Jim Warner <james.warner@comcast.net>
After revisiting the issue of a new field, combining 2
existing fields (RES and SWAP), I've decided it indeed
makes sense. After all, with the vastly expanded field
capability and the ease of adding new fields, it would
save some precious horizontal screen real estate while
also eliminating some mental/manual user calculations.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/top-enhancements-i-hopehttp://www.freelists.org/post/procps/top-regression-reports
Signed-off-by: Jim Warner <james.warner@comcast.net>
top/top.1 | 23 ++++++++++++++---------
top/top.c | 14 ++++++++++++--
top/top.h | 6 ++++++
top/top_nls.c | 3 +++
4 files changed, 35 insertions(+), 11 deletions(-)
This commit just gathers all the logic associated with
resetting/normalizing a single window in one function.
In the future, should the window structure be expanded
to support added functionality, the act of maintaining
it will have been made a little bit easier, hopefully.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
When true line input editing with paste capability was
was re-introduced in the commit below, the concept for
the distinct insert/overtype mode was also introduced.
But such a distinction did not survive an <Enter> key.
With this commit, the cursor state is made persistent.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 477b10c0bd
Signed-off-by: Jim Warner <james.warner@comcast.net>
When both 'kill' and 'renice' commands were changed to
provide a default pid, the 'n' command (maximum tasks)
should have also changed to continue to accept just an
<Enter> key under the get_int function's new protocol.
This patch corrects that behavior, accepting no input.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 39f4067c66
Signed-off-by: Jim Warner <james.warner@comcast.net>
The original implementation of input line recall keeps
strings in the order established when initially added.
With this commit, that has been changed so any matched
string moves to the top of the saved input line stack.
[ well technically not the top since that's occupied ]
[ by an 'empty' string which serves multiple masters ]
Thus, the most frequently referenced strings over time
will percolate up and remain the most easily recalled.
But just in case anybody prefers the strict historical
ordering, a #define can restore the original behavior.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 2efe275512
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that line input offers users full editing freedom,
if top were to be suspended after issuing a prompt for
input, upon resumption an extra keystroke is necessary
to satisfy the outstanding read & refresh the display.
With this patch that extra keystroke is not necessary.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 477b10c0bd
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch fixes the single stinkin' source line which
was responsible for breaking the top idle-mode toggle.
Without this change, either 'u' or 'U' must be invoked
just once before the 'i' command would show something.
(yes, everything's perfectly justified once again but)
(i'm not very happy over the need for this damn patch)
Reference(s):
commit d04297843f
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this commit, users can now retrieve previous line
input for re-editing and/or re-input using the Up/Down
arrow keys (or their aliases). This mirrors the 'bash'
or 'less' interface and represents a major enhancement
achieved via a somewhat minor impact to our code base.
[ 33 lines of code, 5 closing braces & some comments ]
[ all in 1 function, when TERMIOS_ONLY isn't defined ]
Currently, the upper limit for such recallable strings
has been set at 50 but that could be easily increased.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch changes the TERMIO_PROXY define back to the
former TERMIOS_ONLY thus changing the top default too.
Plus we can now use true line input editing while also
retaining paste capability. That former native termios
support provided only a limited destructive backspace.
Now we exploit the Left/Right arrow keys, Home/End and
Delete. Plus, the Insert key can toggle overtype mode!
[ The stage is now set for a really huge improvement ]
[ to any user input terminated with the <Enter> key. ]
[ So please stay tuned for the next patch to arrive! ]
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit fa21a6ca81
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this commit top can now display users which match
a user id/name or just those users which do not match.
The distinction is based on the presence or absence of
a leading exclamation point '!' (C negation operator).
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
Wishlist, http://bugs.debian.org/682086
Signed-off-by: Jim Warner <james.warner@comcast.net>
Lately, top has begun to rely more and more on dynamic
memory allocations rather than the static buffers that
were found in many of its structures. This was perhaps
most evident in the increasing use of the strdup call.
This commit trades that function call for the internal
equivalent which will protect us from malloc failures.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit corrects one reference to 'decimal place'.
Even though a running top supports a delay interval of
unlimited precision, and a delay interval of thousands
of a second in the rcfile, we intentionally imply that
any delay interval is limited to tenths of a sec only.
Later in the man document, in section 7a, one finds an
admission that a user can set any desired delay value.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/tt,4
Signed-off-by: Jim Warner <james.warner@comcast.net>
A recent commit, that was intended to normalize cursor
handling, unintentionally exposed the cursor following
an Inspect 'Locate' request. This change will hide the
cursor once again through inst_view_choice's lifetime.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit f3a87cf634
Signed-off-by: Jim Warner <james.warner@comcast.net>
When top was changed to allow some core dumps, the two
potential end-of-job reports were disabled by mistake.
Later, that was corrected so that those reports always
were allowed, if the respective #defines were enabled.
However, if there was an early exit via a command line
option or an error, those reports should not be shown.
This commit may have gotten it right on our third try!
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 1da293bf59
commit d747659ad8
Signed-off-by: Jim Warner <james.warner@comcast.net>
When two somewhat cryptic error messages were recently
changed to more user friendly text, the logic limiting
maximum columns was left unchanged at six. This always
was a rather arbitrary limit but now the revised error
message could actually be misleading (ok, a huge lie).
With a 1 line code change (macro actually), this patch
lifts the internal restriction on maximum columns. Now
the real limit is based on a window's physical x-axis.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 5a27c8095ehttp://www.freelists.org/post/procps/top-won-the-sigwinch-war,6
Signed-off-by: Jim Warner <james.warner@comcast.net>
A scrollback buffer used in several terminal emulators
could be a real inconvenience to a user following some
resize operations. Extra keystroke(s) would frequently
be required in order to properly render top's display.
After much sleuthing we unearthed two terminfo strings
which have the effect of disabling/restoring that darn
scrollback buffer. They were well hidden under a title
of strings 'to start/end programs using cup'. In turn,
'cup' deals with a tty's cursor addressing capability.
We don't care what you call them or what they refer to
so long as they get the job done. And these really do!
Be advised, however, that there are some side effects,
several of which can even be considered as beneficial:
. enter_ca_mode/smcup/ti disables scrollback buffering
( and that's good, it's what we had always hoped for )
. exit_ca_mode/rmcup/te restores the scrollback buffer
( but also restores screen contents existing pre-top )
( which is different from former program end results )
( where that last rendered screen was left untouched )
. the above screen replacement would impact ^Z suspend
( thus we keep the scrollback buffer disabled during )
( the suspend/resume sequence so that the users will )
( have a visual clue that top is suspended not ended )
If a terminal does not support these terminfo strings,
we will revert to top's former behavior at program end
where we position the cursor at screen bottom and then
output a single newline character. This will prevent a
shell prompt from embedding within top's final screen.
This commit's approach has been tested under a variety
of emulators and window managers, many of which linked
with libvte and others that employed their own scheme.
Examples are: gnome_terminal; kde konsole; lxterminal;
terminator; terminology; urxvt; xfce4-terminal; xterm.
I do now believe that the whole SIGWINCH deal is done!
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/top-won-the-sigwinch-warhttp://www.freelists.org/post/procps/top-won-the-sigwinch-war,4
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit standardizes the usage of several terminfo
strings concerned with cursor position and visibility.
Henceforth we will adopt the following informal rules:
. Cap_home vs. Cap_clr_scr is preferred where possible
. Cap_curs_huge will be used with prompts for line i/p
. Cap_curs_huge will be used with help & color mapping
. Cap_curs_hide will be in effect in any other context
We've also added a missing Cap_clr_scr to the 2nd help
screen whenever the SIGWINCH interrupt was recognized.
This prevents a 'duplicated' row from appearing at the
top of the display (when resizing from small to large)
depending on an emulator's scrollback buffer contents.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This change involves the Fields Management logic only.
With user position being maintained after signals, the
previous algorithm unfortunately used Cap_clr_eos with
each iteration of the loop. The screen flicker invited
with that choice was not apparent under all emulators.
With this commit, clearing to end-of-screen has become
conditional on whether or not there was a true resize.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit ba9092ad83
Signed-off-by: Jim Warner <james.warner@comcast.net>
No top #define is enabled and that constitutes default
behavior. So whenever a default behavior should change
the define must be changed too if it is to remain off.
This commit simply changes top's default behavior with
respect to allowing/suppressing any potential flood of
SIGWINCH during resize operations, if running under X.
Formerly top would block those signals to reduce costs
of repeated refreshes. That yields a requirement where
the user would have to provide another keystroke for a
final display update. That keystroke may not always be
needed now, but it ultimately depends on some terminal
emulator's scrollback buffer. In any case, the cost of
re-sizing may go up a bit, under most window managers.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit 4f33b6b8c5http://www.freelists.org/post/procps/top-won-the-sigwinch-warhttp://www.freelists.org/post/procps/top-won-the-sigwinch-war,4http://www.freelists.org/post/procps/top-won-the-sigwinch-war,5
Signed-off-by: Jim Warner <james.warner@comcast.net>
After carefully working our way to the point where the
excessive SIGWINCH interrupts are now throttled, along
comes a commit which reverses all those prior efforts.
Actually it doesn't. It simply allows one to choose if
all those efforts should be reversed or remain active.
Why in the world would you even want to consider that?
Quite simply, to opt for responsiveness over overhead.
Oh, and depending on the terminal emulator used for X,
by enabling this OFF_SIGWINCH #define you will be able
to avoid the need for an extra keystroke after resize.
Besides it was an interesting programming challenge to
see just how few lines of code would be needed to make
it possible. Bottom line? Only 1 source line required!
(actually 0 lines, since the define disables one line)
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/unwanted-topinspect-window-enclosure-with-the-terminal-size-change
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whew, it was nip-and-tuck there for awhile but finally
we solved the SIGWINCH overload problem one finds with
most X window managers. Now if a window manager should
try to inundate ol' top with repeated SIGWINCH signals
they won't even be received so can't impact us at all.
And we achieve this miracle having never even issued a
sigprocmask, so all the top code executes with signals
totally unblocked. Intuition suggests it probably rubs
even more salt in the wound, but au contraire mon ami!
The key to our success was simply trading the 'select'
call for its cousin 'pselect'. Not only does that call
provide nanosecond granularity (vs. the former's usec)
but it takes a sigset_t parm which can then atomically
block the troublesome SIGWINCH guy until user input or
optional timeout. Net result? No more signal overload!
Now, if only we could just coax all terminal emulators
into one identical standard buffering scheme plus find
some way to emulate the most recent SIGWINCH, it would
be perfect. We would then obviate the user requirement
of typing yet 1 more key before seeing proper results.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/unwanted-topinspect-window-enclosure-with-the-terminal-size-changehttp://www.freelists.org/post/procps/Sourceforge-project,7
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit primarily involves renaming functions plus
reorganizing logic in preparation for the next changes
which will hopefully yield the 'final solution' to the
excessive SIGWINCH signals under most window managers.
In this specific patch, the most significant change is
the introduction of a new 'ioa' function (io avail) to
focus all logic dealing with unsolicited user keyboard
input and exposed to signals and/or optional timeouts.
That new function is where our signal overload will be
ultimately defeated, if it is at all humanly possible.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/unwanted-topinspect-window-enclosure-with-the-terminal-size-change
Signed-off-by: Jim Warner <james.warner@comcast.net>
Prior to this commit, top has always taken the easiest
(safest?) approach when dealing with those troublesome
SIGWINCH interrupts. Whenever the user was on a screen
other than the main display, any signal received would
force an immediate exit, returning to the main screen.
With these changes, top will retain the user's current
position regardless of what screen he/she was viewing.
In support the following additional changes were made:
* the initial help screen requires an explicit end key
` not 'any other key' formerly used to request an exit
* the colors mapping screen instructions were improved
* ^Z response was made immediate, eliminating the flag
* the sigaction's SA_RESTART flag had to be eliminated
* sigprocmask logic was normailize to the bare minimum
* the POSIX.1-2004 async-signal safe functions used in
` the signal handlers were acknowledged and documented
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
http://www.freelists.org/post/procps/unwanted-topinspect-window-enclosure-with-the-terminal-size-change
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just addresses the following minor issues:
. eliminate the leading tab character upon error exits
. standardized single key input as 'keyin', not 'chin'
. symbolic keys changed to guarantee no negative value
. placed most 'case' statement labels on a unique line
. standardized lvalue/rvalue convention in while loops
. fixed prototype declaration in the 'debug_END' macro
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
Some testing under a new distro revealed what appeared
to be a broken top Inspect request. When the selection
was made, the resulting output was scrambled/scrunched
at the bottom of the screen (as if ^J's were missing).
This anomaly surfaced under Fedora-18 which happens to
use the above ncurses version. The bug was not present
in version 5.9.20120714 (available with openSUSE 12.2)
or the more widely available version of: 5.9.20110404.
It has now been confirmed that this problem originated
in version 5.9.20120825. It was then that buffering of
output was changed from stdio to some internal ncurses
scheme so as to avoid problems with its SIGTSTP logic.
Thanks to a very prompt response from Thomas E. Dickey
we also learned that contrary to the documentation the
putp logic does not call putchar internally. Thus, the
single putchar that Inspect was employing was actually
mixing 2 different buffering schemes: ncurses & stdio.
Thus, from now on we'll use putp() exclusively and try
to achieve single char output as efficiently as we can
while meeting that putp() string argument requirement.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
https://bugzilla.redhat.com/892674
Signed-off-by: Jim Warner <james.warner@comcast.net>
There existed a small chance that the display could be
corrupted when a search string was found within a row.
For that to happen, conditions like these were needed:
. a very short Locate string was active in some window
. the string matched part of a terminfo <esc> sequence
. that sequence was used in highlighting running tasks
. the 'x' toggle was active (sort column highlighting)
One solution to this potential problem was to manually
turn off sort column highlighting before using Locate.
But rather than rely on a user remedy, we'll automate.
Since other top provisions were already being enforced
when Locate was in use (off 'i' and/or 'u'/'U'), we'll
now also force column highlighting off when the search
string in a given window is not empty. However, unlike
idle tasks and user filtering, when that search string
*is* emptied, we restore highlighting for that window.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just addresses the following minor issues:
. restored both lost end-of-job reporting capabilities
. added missing initializers to the DEF_RCFILE #define
. added 'nls_maybe' eye-catcher to the 'Scaled_sfxtab'
. removed a now superfluous 'READMINSZ' assertion test
. man document references to 'top' are more consistent
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
This potential problem is caused by frequently spawned
and short lived tasks which happen to sort above a row
containing a match from an active Locate request. It's
most likely to be visible when under Forest View mode.
This commit will eliminate a potential duplicated row.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Both of the 'file' and 'pipe' Inspect read buffers are
always 2048 bytes bigger than is actually needed which
provided for some slightly simplified row paint logic.
However, with no real rcfile inspect entries, and thus
operating in 'demo' mode, the allocated buffer is only
2048 bytes total. This can produce a valgrind warning.
This commit simply puts the inspect 'demo' buffer on a
par with other allocated real buffers (an extra 2048).
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
In a effort to anticipate a potential future wishlist,
the recent '-o' sort override command line switch will
now support an override of the sort direction as well.
By prepending a '+' or '-' to any valid field name the
user will be able to guarantee a specific desired sort
direction. The '+' forces a high-to-low (normal) order
while a '-' reverses that to yield a low-to-high sort.
Without this addition users would be left to the mercy
of whatever was last specified for Curwin as reflected
in the rcfile or top's default of a high-to-low order.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Signed-off-by: Jim Warner <james.warner@comcast.net>
The recent change to task area memory scaling was just
a little short of optimum in its consistency and upper
limits. In fact, top could only scale memory fields up
to a maximum of 99.9999 TiB (with VIRT a little more).
While that seems like more than enough it was actually
artificially low, due to an unnecessary decimal place.
So, this commit standardizes both precision and widths
to achieve a minimum amount of scaling beyond the user
requested target plus reclaim some horizontal spacing.
. VIRT & DATA are now 7 bytes wide (not eight and six)
. other memory fields are 6 wide (were formerly seven)
. as before, KiB shows whole numbers only (no decimal)
. MiB, for its precision, shows a single decimal place
. all other memory ranges display three decimal places
The net result is a more homogeneous display with less
forced scaling and the recovery of three lost columns.
(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-enhancements-i-hope,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will allow user filtering as long as there
is a valid number representing a potential user ID. It
will serve, for example, chroot environments where the
specific user may be unknown to a host, or vice versa.
(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-enhancements-i-hope,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit was adapted from the openSUSE patch, whose
original comments appear between the --- marker below.
It should be noted, however, that the original changes
were ineffective (wasted) because 'Batch' mode had not
yet been set when signals were being checked and their
handlers established. Thus, SIGHUP was never bypassed.
(of course, only our comments are perfectly justified)
------------------------------------------------------
Do not setup SIGHUP signal handler if we are in the batch mode
Top enables a signal handler for the SIGHUP signal (loss of terminal). While
this makes sense for top's default interactive mode, it doesn't make any sense
for batch mode. If you run top in nohup just to collect data over time and
disconnect top finishes which is not what one would expect.
------------------------------------------------------
Reference(s):
http://www.freelists.org/post/procps/top-enhancements-i-hope,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
The delay interval is kept in the rcfile in a floating
point format and is thus susceptible to changes in the
locale between invocations. So values written as #,###
could not be read if a new locale uses decimal points.
This commit takes control of our own decimal point and
will henceforth make top immune to locale switcharoos.
(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-has-a-localedpendent-config-file-toprchttp://lists.opensuse.org/opensuse-bugs/2012-12/msg01466.html
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 is doubtless not quite the solution envisioned by
the submitter, but 'V' should probably never have been
used as an alias for 'v' now that we have forest-view.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s):
Bug-Redhat: https://bugzilla.redhat.com/848290
Signed-off-by: Jim Warner <james.warner@comcast.net>
When 'type' was added to the alternate status line for
the '=' key, the need for the demonstration 'type' was
overlooked. This commit avoids the '(null)' potential.
(now that we know a '.' + 2 spaces is squeezed to one)
(everything's perfectly justified, but it's just luck)
Reference(s);
commit 3b2b9a95e6
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the recent inspect search highlight provisions in
place, the lack of highlighting in task based searches
has grown from being only irritating to a real defect.
Thus, this commit introduces parallel functionality to
those searches initiated within a visible task window.
And just as separate inspect searches are possible for
each selection, per window task searches are provided.
However, it should be noted that there are differences
between task based searches and inspect type searches:
* There is no concept of out-of-view data when dealing
. with task rows -- if the data can't bee seen, it has
. not, in fact, been constructed from a proc_t struct.
* While inspect data is output at the character level,
. up to now all task display data was only potentially
. output and it was always based on a complete string.
* With task search highlighting, rows now containing a
. match must be output in pieces and, therefore, can't
. be optimized away like other rows which haven't been
. been altered. This is because top cannot predict the
. the contents of a search string or, how many matches
. might occur in a given row. Short search strings and
. many matches would raise buffer needs geometrically.
(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 extends Inspect provisions for 'find/next'
to each individual selection. Thus a user can maintain
multiple active searches without having to reissue the
locate command whenever the current selection changes.
To emphasize this feature the View screen now displays
the current active locate string or 'N/A' if inactive.
Such a reminder is important when no found matches are
present on the 1st display page, given that they would
otherwise be apparent via the additional highlighting.
(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>
We have modeled the Inspect search provisions on those
provided by the 'less' pager. With this commit we take
the next step and provide for highlighting any strings
matched (and in view). Of course, top will continue to
adjust the beginning column so as to bring out-of-view
matches into view, while highlighting visible matches.
However, top won't emulate every 'less' behavior since
the following are seen as flaws in the user interface.
* when viewing true binary data, less makes no attempt
. to smooth the right margin by truncating unprintable
. symbols, thus creatng ragged unappealing right edges
* when viewing true binary data, less will always fail
. search requests regardless of surrounding characters
* less refuses to bring out-of-view found matches into
. view by adjusting the left-most column, if necessary
(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>
Previously top would warn users if an older version of
an rcfile was about to be overwritten. That's assuming
that RCFILE_NOERR was not defined. This left, however,
other potential rcfile issues or questions unattended.
For example, if a faulty 'inspect' redirected echo had
overwritten all window entries or if the inspect entry
was not 'pipe' or 'file' (actually, just a 'p' or 'f')
then top would silently accept it but look no further.
With this commit top will try to process every inspect
entry, while preserving unrecognized entries. Plus all
other non-fatal rcfile errors will now alert a user to
the potential overwrite when the 'W' command is given.
(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>
The Inspect find algorithm has always been challenging
given the possibility that 'rows' might contain binary
data. Be that as it may, two small changes have proven
to dramatically improve the performance of such scans.
The first involves the case wherein if no match on the
'substring' portion of a row was found, then a pointer
representing the substring was increased by the length
of the search string, not the better/longer substring.
Thus, portions of the substring were always rescanned!
The second performance boost was achieved in this way:
pre-scanning each raw row for just the first character
in the search string now determines if a full match is
even possible. Therefore, repeated unproductive strstr
calls on individual substrings within that row will be
avoided. In a nutshell, 1 'if' with '}' did the trick!
(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 improves display performance when the user
has scrolled horizontally past the end of a top 'row'.
We can avoid the need to memset our buffer with spaces
and putp those spaces individually by exploiting logic
that already exists. If one '\n' character is inserted
into the buffer instead, the next terminfo string sent
will be Cap_clr_eol achieving exactly the same effect!
(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 introduces an extremely powerful, flexible
brand new capability. Now, users can pause the normal
iterative display and inspect the contents of any file
or output from any script, command, or even pipelines.
It's invoked via the 'Y' interactive command which, in
turn, is supported with simple user supplied additions
as new entries in the top personal configuration file.
A separate new 'Inspect' window supports scrolling and
searching, similar to the main top display. Except it
extends existing 'L'/'&' (locate/locate-next) commands
so that an out-of-view match automatically adjusts the
horizontal position bringing such data into view. And
it provides for multiple successive same line matches.
Also, the basic 'more/less' navigation keys are active
in this new 'Inspect' window, to ease user transition.
There are no program changes required when entries are
added to or deleted from the rcfile. And there are no
known limits to the complexity of a script, command or
pipeline, other than the unidirectional nature imposed
by the 'popen' function call which top cannot violate.
Since it's impossible to predict exactly what contents
will be generated, top treats all output as raw binary
data. Any control characters display in '^C' notation
while all other unprintable characters show as '<AB>'.
The biggest problem encountered was with the find/next
capability since that strstr guy was really diminished
given the possibility that numerous 'strings' could be
encountered *within* many of top's raw, binary 'rows'.
Oh, and another problem was in maintaining the perfect
left & right text justification of this commit message
along with all of the commit summaries. Some of those
summaries (like this very one) are of course, slightly
shorter, to make room for the 'man document' addition.
Enjoy!
Signed-off-by: Jim Warner <james.warner@comcast.net>
As an aid to the above 2 commands, and as a prelude to
an upcoming 'inspect other output' capability, the act
of selecting a process for either has been simplified.
Positioning a task as the first one displayed, via the
up/down arrow keys, will now establish it as a default
selection for the appropriate command. Thus, that pid
will then be incorporated in a subsequent input prompt.
Signed-off-by: Jim Warner <james.warner@comcast.net>
An earlier commit improved the scroll coordinates
message performance by offloading most of the work
to those occasions when column headers were rebuilt.
The only remaining per-frame costs were the addition
of some terminfo escapes and the Frame_maxtask count.
This commit further reduces those per-frame costs to
the absolute minimum.
Reference:
commit fbfaa868ba
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'refactor and enhance column width management'
recent redesign produced many subsequent benefits,
the latest of which is automatically sized fixed-width
non-scalable columns.
As expected, there was a cost associated with these
many enhancements. That cost has now been identified
as a 1-4% performance degradation, depending on which
fields are being displayed.
This increased cost arises principally from current
drawing related function calls, whereas top-3.3.3 did
most of its drawing via macros effectively inlining
those duties.
This commit inlines the equivalent drawing functions,
thus eliminating the function call penalty, and places
this top on a par with top-3.3.3. The trade off is a
modest additional 4k in executable size.
Signed-off-by: Jim Warner <james.warner@comcast.net>
