In the commit referenced below, in addition to several
tweaks to comments, 3 fields were no longer assured of
being present in the results stacks. However, 2 of the
3 fields might, in fact, be required even if they were
not currently being displayed in any of the 4 windows.
The PIDS_CMD is used in two separate 'Inspect' headers
('Y' command) and the PIDS_ID_EUID is required if that
'User Filter' ('u' or 'U' command) was being employed.
That latter field's inclusion will be made conditional
but the former field must be unconditionally included.
( for old top, PIDS_CMD would have always been there )
Reference(s):
commit 4e4debda9b
Signed-off-by: Jim Warner <james.warner@comcast.net>
No longer will ps print nwchan as 'ffffff', '-' or '1'
since the proc/PID/stat wchan field didn't represent a
real address anyway. Rather, the field will henceforth
output a dash ('-'), the ps customary 'not available'.
That man document was also tweaked to better represent
actual behavior. An asterisk ('*') was never shown for
threaded tasks and that dash ('-') usually didn't mean
running tasks (sometimes associated with permissions).
Signed-off-by: Jim Warner <james.warner@comcast.net>
Removing the Item_table 'stat' oldflags for WCHAN_ADDR
was wrong since that 'stat' field is not a constant 0.
Rather, it could assume these 3 values: -1, 0, and +1.
I have not been able to pin down a '-1' result, but it
probably means some sort of permission error (-EPERM).
The '1' or '0' values were supposed to distinguish the
tasks that were or were not blocked (whether there was
a wchan address). However, in practice there is little
correlation between those values and availability of a
kernel symbol in /proc/$$/wchan (perhaps due to race).
Anyway, the real point is that a 'stat' wchan does not
now intentionally contain an address. Thus, outputting
'ffffff', '-' or '1' in programs like ps is senseless.
So this patch just eliminates PIDS_WCHAN_ADDR from our
item enumerators leaving only the PIDS_WCHAN_NAME guy.
Now the new library can't be blamed for bad addresses!
Reference(s):
. removed Item_table 'oldflags'
commit c4aa6c0ab4
. linux removal of wchan addresses
commit b2f73922d119686323f14fbbe46587f863852328
Signed-off-by: Jim Warner <james.warner@comcast.net>
It makes no sense to begin our tracked nested level at
'1' then later require a '1' to be subtracted from the
level as artwork and indentation is added for display.
By beginning such tracked levels at zero, we can avoid
the need to adjust it & use it directly in a snprintf.
Signed-off-by: Jim Warner <james.warner@comcast.net>
It makes no sense to begin our tracked nested level at
'1' then later require a '1' to be subtracted from the
level as artwork and indentation is added for display.
By beginning such tracked levels at zero, we can avoid
the need to adjust it & use it directly in a snprintf.
[ this commit parallels a patch in our newlib branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
In some environments, 100 * nr_active_objs is calculated at first,
and the result of lower 32bits is divided by nr_objs. This occurs
even in a 64-bit architecture. So nr_active_objes > 42949672, %use
will be incorrect.
This fix casts type of nr_active_objs to float to calculate
correctly the %use in 32-bit/64-bit architectures.
Signed-off-by: Takayuki Nagata <tnagata@redhat.com>
This reverts commit 99d71ad581.
When nr_active_objs / nr_objs is calculated, the result will be 1
or 0 since the variables are integer. So the commit is wrong.
This patch just parallels some adjustments/corrections
which were also implemented under the 'newlib' branch.
[ remaining differences between man documents relate ]
[ to old kernels with topic '2b. TASK and CPU State' ]
[ and a note in '4c. SORTING' for TTY + WCHAN fields ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
It would have been nice to remove this 'nDRT' guy from
the fields management screen and man document as well.
But, while this version of top could be made to handle
an older rcfile, the reverse would not have been true.
Besides, it's been zero for so long already we'll just
include a 'deprecated' note in top's man page for now.
[ the 'nTH ' field number was corrected in there too ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
It seems inappropriate to blindly include fields known
to always be zero in our brand new library. Therefore,
this patch removes support for three such enumerators.
[ that stat 'it_real_value' (PIDS_ALARM) field could ]
[ have been made obsolete before a linux 2.6 release ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just contains some tweaks to comments plus
a few adjustments to whitespace for alignment purposes
and a normalization of the header inclusion #define's.
[ plus a spelling error in one header file was fixed ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Maybe some folks still need a few .gitconfig tweaks to
catch the trailing whitespace errors a little earlier.
Or, at the least, after a local commit they should do:
$ git diff HEAD~1
[ and then check if git marks any with his red blobs ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When this module was upgraded to 3rd generation in the
patch referenced below, numa node support was migrated
from the top program into newlib. The 'guest_nice' and
'guest' tics were overlooked as top did not need them.
So, this commit corrects that oversight and achieves a
proper symmetry between the cpu & numa jiffies counts.
Reference(s):
. 3rd gen redesign, numa support imported
commit abc71a46ad
Signed-off-by: Jim Warner <james.warner@comcast.net>
Maybe some folks still need a few .gitconfig tweaks to
catch the trailing whitespace errors a little earlier.
Or, at the least, after a local commit they should do:
$ git diff HEAD~1
[ and then check if git marks any with his red blobs ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
A priming read at 'new' time in that <slabinfo> module
was important so that permission problems are detected
early. Plus, it also had the potential of making delta
values valid when 'get' or 'select' were first called.
It is for that latter reason that such a read was also
incorporated in the <diskstats> module 'new' function.
No other module, however, employed such priming reads.
This patch just brings those potential benefits to all
of our other newlib modules with the exception of that
<pids> guy. That module is, of necessity, sufficiently
different from those others to justify such exclusion.
Not only are there precious few DELTA enums in <pids>,
but the costs of a priming read would be much greater.
[ otherwise, these newly added priming reads have no ]
[ measurable negative impact on performance/timings. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The <slabinfo> header provides 3 groups of enumerators
with prefixes of SLABINFO, SLABS & SLABNODE. The first
is strictly user oriented & isn't supported internally
by any structure. The other two, however, have structs
associated with 'em but, unfortunately, 1 is misnamed.
The 'struct slabs_node' is associated with 'nodes' and
supports the enumerators with the SLABNODE prefix. But
the 'struct slabs_hist' was associated with 'hist' yet
supports those enumerators with just the SLABS prefix.
We do not care very much what some structure is called
but we do care about an identifier used manipulate it.
This patch will trade the 'hist' identifier associated
with 'struct slabs_hist' for a more congruous 'slabs'.
[ it's awful when the author can't remember what the ]
[ true meaning of an identifier is after creating it ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
If, in fact, numa nodes are dynamic (like that current
total of on-line cpus) the existing logic was lacking.
It included an early return before checking the total.
So, this commit ensures that the nodes total is always
set or updated consistently in only a single function.
There's no need to set it at the time 'new' is called.
[ and since under our existing code this nodes total ]
[ could never possibly have been zero, the erroneous ]
[ test (with the early return) has now been whacked! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since our library is responsible for NUMA support, and
since the top program already accommodates the lack of
NUMA data, there's no reason that #define NUMA_DISABLE
need be explicitly referenced in the top source files.
Ergo, this commit just eliminates all such references.
Now, top will rely only on procps_stat_reap() results.
Signed-off-by: Jim Warner <james.warner@comcast.net>
sysctl.conf manpage - new NOTES section helps variable listing
sysctl.conf manpage now explains what tools to use to list all modifiable variables.
See merge request !28
Still unhappy with a minor memory leak associated with
libnuma, I experimented with omitting the dlclose that
was issued at module's end. For some reason which will
remain a mystery, the valgrind leak then went bye-bye.
So this patch just omits one use of dlclose and relies
on whatever kernel magic is at work to free the memory
when each process ends. We kept, however, the original
code (now commented-out) to serve as a future caution.
There remains one potential (but unlikely) dlclose use
near the original dlopen. But there will be no leak as
that 'numa_node_of_cpu' will not yet have been called.
This seems to be the culprit that triggers such leaks.
None of this libnuma shit would likely have come close
to hitting our fan had the numa developers provided us
with 'new' and 'unref' functions like our newlib does.
[ this commit parallels a patch in our newlib branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This just brings the newlib branch NEWS into line with
the current version from our master branch since those
changes have already been incorporated in this branch.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Still unhappy with a minor memory leak associated with
libnuma, I experimented with omitting the dlclose that
was issued at module's end. For some reason which will
remain a mystery, the valgrind leak then went bye-bye.
So this patch just omits one use of dlclose and relies
on whatever kernel magic is at work to free the memory
when each process ends. We kept, however, the original
code (now commented-out) to serve as a future caution.
There remains one potential (but unlikely) dlclose use
near the original dlopen. But there will be no leak as
that 'numa_node_of_cpu' will not yet have been called.
This seems to be the culprit that triggers such leaks.
None of this libnuma shit would likely have come close
to hitting our fan had the numa developers provided us
with 'new' and 'unref' functions like our newlib does.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Add a warning if you specify a command over 15 characters and don't
use the -f command.
This is a pick of two patches from master:
24fd260 pgrep: Fix off by one error in line check
4a7f9fc pgrep - adds warning that pattern exceeds 15 chars without
References:
!25
There is now a warning if your command is longer than 15 characters
and therefore can never match. Except it was checking for more than
16 characters.
Adjusted this and added a test case.
References:
!25
commit 8e8835b2ee
pgrep - adds warning that pattern exceeds 15 chars without '-f' option
Resolves many questions seen on forums around the web. Adds a decent warning about the behaviour.<br>
Ideas about better text?
See merge request !25
kill -l SIGHUP (or any other signal-name prefixed with "SIG")
would cause free() to be called with a bad pointer instead of
a pointer to what was allocated. Fix this and add test-case.
kill: Fix free() with bad pointer on SIG-prefixed signal-name
kill -l SIGHUP (or any other signal-name prefixed with "SIG")
would cause free() to be called with a bad pointer instead of
a pointer to what was allocated. Fix this and add test-case.
See merge request !26
Ever since its introduction, the 'x' (extended format)
option has employed strncmp to parse those smaps keys.
Such an approach worked well as long as those prefixes
were guaranteed to be unique. But, with the 4.3 kernel
a new 'SwapPss' field was added to those within smaps.
That triggered a 2nd match for the 'Swap' logic which,
in turn, resulted in a duplicate output line of zeros.
So this patch just trades strncmp for strcmp, avoiding
potential future problems when /proc/$$/smaps evolves.
Reference(s):
. recent bug report
https://bugzilla.redhat.com/show_bug.cgi?id=1374061
. linux 4.3 kernel introduces SwapPss
commit 8334b96221ff0dcbde4873d31eb4d84774ed8ed4
. original pmap -x option introduction
commit 380cc1e908
Signed-off-by: Jim Warner <james.warner@comcast.net>
Recent profiling and timings have resulted in improved
newlib performance. This patch completes that process.
It just normalizes naming conventions employed for all
allocations involving reaped stacks & history support.
The modules offering a 'reap' function will also offer
the now standardized corresponding STACKS_INCR define.
The modules which provide dynamic history support will
now have a separate #define called NEWOLD_INCR used in
allocations/reallocations. And, while values currently
are set equal to that STACKS_INCR value, in the future
some reason for divorcing those two may be discovered.
----------------------------- for future reference ---
In those modules which contain the STACKS_INCR #define
it is tempting to specify a large value so as to avoid
repeated calls to malloc/realloc. However, in doing so
an extra runtime price will be paid in 'cleanup_stack'
calls with any iterative programs like top or slabtop.
So, with the current values a balance has been sought.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just brings some comments plus identifiers
into agreement with the current newlib implementation.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ever since its introduction, the 'x' (extended format)
option has employed strncmp to parse those smaps keys.
Such an approach worked well as long as those prefixes
were guaranteed to be unique. But, with the 4.3 kernel
a new 'SwapPss' field was added to those within smaps.
That triggered a 2nd match for the 'Swap' logic which,
in turn, resulted in a duplicate output line of zeros.
So this patch just trades strncmp for strcmp, avoiding
potential future problems when /proc/$$/smaps evolves.
Reference(s):
. recent bug report
https://bugzilla.redhat.com/show_bug.cgi?id=1374061
. linux 4.3 kernel introduces SwapPss
commit 8334b96221ff0dcbde4873d31eb4d84774ed8ed4
. original pmap -x option introduction
commit 380cc1e908
Signed-off-by: Jim Warner <james.warner@comcast.net>
kill -l SIGHUP (or any other signal-name prefixed with "SIG")
would cause free() to be called with a bad pointer instead of
a pointer to what was allocated. Fix this and add test-case.
FreeBSD doesn't have SIGPWR so makes no sense in warning and assuming
its 29.
Picked from master, but the file has moved from proc/sig.c to
library/signals.c
References:
commit 8abd0c92abhttps://bugs.debian/org/832148
Signed-off-by: Craig Small <csmall@enc.com.au>
After discovering those terrible costs associated with
/proc/status vs. /proc/stat, the build_header function
changed to favor the latter for a field found in both.
Well, low-and-behold, this top program still used some
flags that needlessly caused 'status' to still be read
when 'statm' could have served. And, while top's needs
require conversion from pages to KiB, that's still far
less costly than reading that gosh darn 'status' file.
[ this patch parallels similar changes to newlib top ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Long ago, in a galaxy far away, top was convinced that
/proc/stat was to be favored over /proc/status if some
field could be satisfied with either. This was done to
avoid extra costs of 64-bit math for 32-bit platforms.
Well, its time to acknowledge the prevalence of 64-bit
platforms. And in such an environment there is a large
hidden cost currently if using status instead of stat.
In fact, that cost difference can be as high as 1400%.
So, this commit will coax top into favoring that least
costly route while also fixing an EU_TGD library flag.
[ this patch parallels similar changes to newlib top ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Profiling revealed a large amount of time spent in the
'escape_str_utf8' function (escape.c) with both of our
NLS branches (newlib and master). That same result was
not seen under an ancient top-3.2.8 program & library.
Well, the 3.2.8 result was ultimately explained by the
absence of a 'setlocale', necessary under NLS support.
Thus, when that ancient library tested for locale, all
it got was 'ANSI_...' & assumed 'UTF-8' wasn't active.
But after a hack to that ancient code to place it on a
par with newlib/master, I still found cost differences
that led me to revisit an old change referenced below.
It turns out that 'iswprint' costs far more than would
a call of 'isprint', even with the extra support code.
So this commit just reverts that five year old change.
[ this patch parallels a similar change under newlib ]
Reference(s):
commit 7b0fc19e9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
Profiling revealed a large amount of time spent in the
'escape_str_utf8' function (escape.c) with both of our
NLS branches (newlib and master). That same result was
not seen under an ancient top-3.2.8 program & library.
Well, the 3.2.8 result was ultimately explained by the
absence of a 'setlocale', necessary under NLS support.
Thus, when that ancient library tested for locale, all
it got was 'ANSI_...' & assumed 'UTF-8' wasn't active.
But after a hack to that ancient code to place it on a
par with newlib/master, I still found cost differences
that led me to revisit an old change referenced below.
It turns out that 'iswprint' costs far more than would
a call of 'isprint', even with the extra support code.
So this commit just reverts that five year old change.
Reference(s):
commit 7b0fc19e9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
