After discovering those terrible costs associated with
/proc/status vs. /proc/stat, our library changed so as
to favor the latter if a field could be met by either.
Well, low-and-behold, this top program had chosen some
item enumerators that needlessly caused 'status' to be
accessed when 'statm' could be used instead. And while
top's needs require conversion from pages to KiB, that
is still far less costly than that damn 'status' file.
[ this was found when comparing newlib top against a ]
[ 3.2.8 ancient top since the current master top was ]
[ suffering from the exact same 'status' deficiency. ]
[ and, no way was top-3.2.8 going to beat newlib top ]
[ by 50% - we'll allow only a 1-10% occasional loss! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
After doing some profiling and timings, then comparing
newlib top to the existing 3.3.12 version, I concluded
top should avoid stack results unless actually needed.
Not only will stack depth be kept to minimums, but the
new library can save some otherwise wasted pathlength.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch, top has ensured that base library VAL
macros are never found inside function bodies. Rather,
they are used solely to support global derived macros.
Program functions remain free to further tailor macros
but they'll now always be based on the top derivative.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is a response to errors found in those type
references now that our library allows for validation.
In two cases, former assignments to a result structure
could no longer employ that VAL macro if validation is
active. Thus, direct reference to some stack was used.
For the record, those instances were to be found here:
. ps - uses PIDS_extra to store the cooked pcpu values
. top - uses PIDS_extra to store the forest view level
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since the VAL macro now requires a 4th parameter, this
commit simply adds the 'info' context structure to it.
In some cases, that context structure needed to become
global, since it was referenced in multiple functions.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch is the response to changes in <pids> types.
These additional modifications were also incorporated.
. ps -------------------------------------------------
pr_wname was eliminated as it just duplicated pr_wchan
pr_wchan referenced WCHAN_ADDR in error, vs WCHAN_NAME
pr_nwchan referenced WCHAN_NAME, not proper WCHAN_ADDR
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit provides for raising the total displayable
fields from its current 70 to 86. It also bumps the id
in an rcfile representing the version from 'i' to 'j'.
The increase in number of fields will make sharing the
rcfile with an older top, once it's saved, impossible.
These changes are being done via a #define rather than
hard coded so any such sharing will still be possible.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With this patch we've completed a progression toward a
standard approach to naming conventions which follows:
* Only functions will begin with that 'procps_' prefix
. ........................................... examples
. procps_vmstat_get ()
. procps_diskstats_select ()
- ----------------------------------------------------
* Exposed structures begin with the module/header name
. ........................................... examples
. struct pids_info
. struct stat_reaped
- ----------------------------------------------------
* Item enumerators begin like structs, but capitalized
. ........................................... examples
. VMSTAT_COMPACT_FAIL
. MEMINFO_DELTA_ACTIVE
[ slabinfo varies slightly due to some item variants ]
. SLABINFO_extra
. SLABS_SIZE_ACTIVE
. SLABNODE_OBJS_PER_SLAB
[ could cure with a prefix of SLABINFO, but too long ]
- ----------------------------------------------------
* Other enumerators work exactly like item enumerators
. ........................................... examples
. PIDS_SORT_ASCEND
. STAT_REAP_CPUS_AND_NODES
- ----------------------------------------------------
* Macros and constants begin just like the enumerators
. ........................................... examples
. #define SLABINFO_GET
. #define DISKSTATS_TYPE_DISK
- ----------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whoa, I had never considered an alternative to ncurses
until the issue referenced below was raised. Thus, I'm
surprised to find that 'tparm' was the only impediment
to ultimately utilizing this alternate curses library.
And, while we could have substituted that non-standard
'tiparm' with only 2 arguments, we'll utilize the full
parms compliment in the spirit of that original patch.
Frankly, the task of developing an alternative library
to that ncurses implementation really boggles my mind.
Congratulations to rofl0r, whoever that masked man is.
Reference(s):
. issue raised
https://gitlab.com/procps-ng/procps/issues/38
. netbsd-curses home
https://github.com/sabotage-linux/netbsd-curses
Signed-off-by: Jim Warner <james.warner@comcast.net>
So as to avoid that potential (and inappropriate) numa
library spew to stderr, plus some resulting corruption
of top's display, top buffered stderr output until the
program ended. However, under our new library, timings
have changed meaning the corruption could occur again.
So this patch just relocates the stderr redirect to an
earlier startup point ahead of the 1st call to <STAT>.
[ plus we also fiddle just a tad with a few comments ]
Reference(s):
. original libnuma fix
commit 35dc6dcc49
. original redhat discussion
https://bugzilla.redhat.com/show_bug.cgi?id=998678
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the change to struct pids_fetch, we'll just trade
some dot ('.') code for some pointer to ('->') syntax.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch contains the following collection of stuff:
. an identifier Pids_read is now Pids_reap like <stat>
. eliminate redundant param from the <stat> VAL macros
. eliminate the unneeded tailored <stat> SUM_VAL macro
. corrected comment spelling for 'gouped' to 'grouped'
Signed-off-by: Jim Warner <james.warner@comcast.net>
This development (only) define can be used to turn top
into a simple text program, disabling termcap effects.
But input (at screen bottom) suffers from a line wrap.
So, this commit just makes the input prompt processing
a little more effective by adding one leading newline.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When experimenting with two macro constants for stat.c
(#define STACKS_INCR & #define NEWOLD_INCR), a bug was
revealed in top, only surfacing if both were set to 1.
At those settings an absolute minimum number of stacks
would be allocated for CPUs & numa NODEs. This in turn
led top to overrun the lessor number of nodes since he
used the cpu index when accessing those numa stack(s).
What he should have been accessing was the cpu stacks.
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
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>
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 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
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>
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>
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>
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>
