Commit Graph

682 Commits

Author SHA1 Message Date
ed neville
0496b39876 uptime: Correctly print pretty/short format
uptime -p would show empty output after 52 weeks of uptime. This commit
is largely the work of Ed but reformatted for newlib branch.

Signed-off-by: Craig Small <csmall@dropbear.xyz>

References:
 procps-ng/procps!141
 procps-ng/procps#217
2021-10-14 19:37:42 +11:00
Jim Warner
ca30741a30 library: ensure thread safety via function substitutes
Even though we we had to abandon the master branch top
multi-thread effort and even though the newlib version
of a multi-threaded top provides no real benefit, that
whole exercise was not wasted. Rather, it has revealed
some deficiencies in our library which this addresses.

If two or more threads in the same address space tried
to use procps_loadavg or procps_uptime simultaneously,
there's a chance they would experience problems due to
thread-unsafe functions our library called internally.

So, this patch switches them for thread-safe versions.

[ along the way we will also make that procps_uptime ]
[ initialization of his 'up' & 'idle' variables mean ]
[ something by delaying the -ERANGE return a little. ]

Reference(s):
https://www.freelists.org/post/procps/a-few-more-patches,7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-10-02 12:55:31 +10:00
Jim Warner
23cfb71366 library: ensure thread safety for all static variables
Even though we we had to abandon the master branch top
multi-thread effort and even though the newlib version
of a multi-threaded top provides no real benefit, that
whole exercise was not wasted. Rather, it has revealed
some deficiencies in our library which this addresses.

If two or more threads in the same address space tried
to access the same api simultaneously, there is a good
chance some function-local static variables will yield
some of those renowned unpredictable results. So, this
patch protects them with the '__thread' storage class.

Reference(s):
https://www.freelists.org/post/procps/a-few-more-patches,7

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-10-02 12:55:31 +10:00
Jim Warner
9a5a155e75 library: trade 2 strstr & atoi calls for 1 sscanf call
Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-24 20:52:10 +10:00
Jim Warner
2a539477b7 library: just eliminate a couple of unnecessary braces
Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-24 20:52:10 +10:00
Jim Warner
96e2220068 library: address major bug in the 'listed_nextpid' guy
Ever since 2003, the 'listed_nextpid' routine has been
misrepresenting its duties. Far from finding processes
in a list given to openproc, it just inserted the next
pid in that list into the passed proc_t as BOTH a tgid
and tid. There was no attempt to validate such values.

The net result is that tid & tgid were valid only with
a thread group leader. When called with a pid for some
sibling thread, the resulting tgid would be incorrect.

With this commit, our little function will now attempt
to validate both the tid and tgid. If this should fail
then the fallback position will be the same as what we
inherited. So we're no worse off & likely much better.

[ note that calling the function with a thread's pid ]
[ likely stems from 2011 when a 'readeither' routine ]
[ was added which dealt with both tasks and threads! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-12 21:34:11 +10:00
Jim Warner
f1aad95cd1 library: disabled some code that now serves no purpose
In the patch shown below, two lines involving the flag
PROC_UID were uncommented (enabled). However given the
construct of the readeither function, it is impossible
for the simple_readtask guy to be called when its TGID
leader has already been ignored. So, let's disable it.

[ it's only now true that the lines serve no purpose ]
[ after the commit shown below tweaked readeither to ]
[ access the base directory of the tgid leader. but, ]
[ before that, the 2 lines should have been enabled! ]

Reference(s):
. two lines uncommented
commit af34cc964a
. tweaked readeither
commit a375262609

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-12 21:34:11 +10:00
Jim Warner
af34cc964a library: repair <pids> api boo-boo in the 'select' i/f
The patch referenced below corrected some flaws in the
procps_pids_select implementation. But, there remained
one flaw which this commit will now hopefully address.

Rather than assume callers wished to select only tasks
and not threads meant a command like 'top -H -p 10329'
works differently under newlib than release 3.3.17. It
fails to honor the '-H' (threads) switch under newlib.

So, to fix that oops, we'll allow that select function
to get threads or tasks depending on its 'which' parm.

Reference(s):
. Oct 2015, some flaws corrected
commit bc616b3615

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-09 22:03:23 +10:00
Jim Warner
a375262609 library: ensure thread group leader retrieval accuracy
With that recent addition of the autogroup provisions,
it became apparent that '/proc/<pid>/task' information
is sometimes incomplete. In fact, there's no autogroup
file at all in any '/proc/<pid>/task/<pid>' directory!

As a result, when the top -H mode was invoked, all the
processes showed a -1 for AGID, even the group leader.

So, this commit will ensure that for every TGID leader
its basic '/proc/<pid>' directory will always be used.
The 'task' subdirectory is now only used for siblings.

[ and it's time that readeither prologue was updated ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-09 22:03:23 +10:00
Jim Warner
631e5d91f3 library: add provision for displaying autogroup values
In the link referenced below there's an explanation of
the linux autogroup feature which has been around ever
since linux-2.6.38. With that explanation there's also
surprising (maybe shocking) revelations about the nice
and renice commands if CONFIG_SCHED_AUTOGROUP was set.

When autogroups are active, such programs are rendered
mostly useless because the nice value will only affect
scheduling priority relative to other processes in the
same autogroup. In order to accomplish what we thought
of as renice, that nice value in /proc/<pid>/autogroup
must be changed. Altering any single member of a group
will also affect every other member of that autogroup.

So, this commit will set the stage for users of newlib
to display autogroup identifiers plus their associated
nice values (now that their importance is understood).

Reference(s):
https://github.com/nlburgin/reallynice

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-09 22:00:23 +10:00
Jim Warner
0360f64027 library: refactor all the readproc.h 'PROC_FILL' flags
The 'PROC_FILL' flags, found in readproc.h, had become
almost unmanageable. The hex values were scattered all
over the map as new flags had been introduced. So this
commit resets all of them and will help ensure any new
flags don't duplicate some already existing hex value.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-08-09 22:00:23 +10:00
Jim Warner
fca8bcbd40 library: standardize 'pointer-to-thing' whitespace use
When declaring a pointer there's usually a space after
the thing-pointed-to and no space between the asterisk
and the pointer-thingy itself. So this commit enforces
such conventions where needed on old library elements.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-07-27 21:17:18 +10:00
Jim Warner
e7acf3caf0 library: correct sources for IO accounting, <pids> api
This patch just brings 'PIDS_IO' source into alignment
with the names being used in that /proc/<pid>/io file.

[ i had my chance to fix them in a whitespace change ]
[ made in the patch referenced below, but i blew it! ]

Reference(s):
commit 2dcbe71f3b

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-06-23 18:23:49 +10:00
Jim Warner
3e94210fe4 library: add new derived smaps_rollup item, <pids> api
That recent addition of USS to the ps program prompted
this change.  Rather than have it (and soon top) add 2
separate items to yield the desired value, we will let
our new library perform the arithmetic when necessary.

Outside of a little extra storage, there is no runtime
costs for such an extension. There is, however, a real
benefit to having such code in the library. Now should
callers choose to sort on this new field, results will
be guaranteed to be what was expected (i.e. accurate).

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-06-17 16:42:58 +10:00
Jim Warner
bf0b3b6522 library: rename/reposition two enumerators, <pids> api
The two special hugetlbfs items were misnamed. The TBL
reference (table) should be TLB (transaction lookaside
buffer). Besides, I never liked their position anyway!

[ and one macro argument tweak is being snuck in too ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-05-02 20:08:38 +10:00
Jim Warner
12543b6c76 library: add support for smaps_rollup file, <pids> api
A couple of people have suggested that smaps_rollup be
added to the ps program and/or top program. This patch
is intended to set the stage for just such extensions.

There are currently 20 displayable items in the rollup
file. And newlib sometimes uses sscanf when populating
the target, sometimes hsearch and one customized gperf
approach. None of these fit well with the smaps items.

Thus, an approach using a simple table lookup was used
and, by disabling 1 code line, it could be made immune
from changes to the items order (unlike a sscanf call)
and doesn't carry the greater cost of a hsearch/gperf.

Note: The next patch will allow top to display some of
these new fields. Then, it'll be possible to determine
the colossal costs of accessing the smaps_rollup file.

Here is a small preview of just what you will discover
when using the command 'time top/top -d0 -n1000' while
configured with just two fields: PID + 1 memory field.

------------------------------------ as a regular user
    with only PID + RES (statm)
real       0m2.605s
user       0m1.060s
sys        0m1.377s
    with only PID + RSS (smaps)
real      0m26.397s                    10x more costly
user       0m1.253s
sys       0m24.915s

----------------- as a root (thus smaps for all tasks)
    with only PID + RES (statm)
real       0m2.651s
user       0m1.177s
sys        0m1.286s
    with only PID + RSS (smaps)
real      0m33.040s                    12x more costly
user       0m1.256s
sys       0m31.533s

Reference(s):
. ps: expose shared/private memory separately
https://gitlab.com/procps-ng/procps/-/issues/201
. top/ps: add support for PSS reporting
https://gitlab.com/procps-ng/procps/-/issues/112

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-29 21:42:44 +10:00
Jim Warner
b921776dad library: some miscellaneous tweaks before smaps_rollup
This commit is strictly cosmetic. It was an attempt to
normalize/standardize/alphabetize those #define/#undef
statements. Some missing #undef's were added plus some
comments regarding sources corrected/standardized too.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-29 21:42:44 +10:00
Jim Warner
2dcbe71f3b library: fix alignment with new 'io' types, <pids> api
The commit referenced below was well done but needed a
small whitespace tweak to preserve existing alignment.

Reference(s):
. io accounting added
commit a7afe06e6f

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-27 21:16:51 +10:00
Craig Small
a7afe06e6f library: adding IO accounting
This is a modification of MR !122 by @renit1609 to fit the new
library.

Problem statement:
The procps library has no PROC_FILLIO flag to
fetch the proc field "/proc/[pid]/io" data
process-wise.
IO Accounting is not included as part of procps.

Requirement:
We have a requirement to fetch process wise
IO utilization which can be used for monitoring.

When looking through the procps library, I see
that IO Accounting (/proc/[pid]/io) is not being
included as part of procps. There is no such
flag like PROC_FILLIO being included in readproc.h .

Solution:
While looking at the implementation done for
other proc fields, I used the spare bits in app code.
I renamed PROC_SPARE_1 as PROC_FILLIO, the spare bit from
PROC_SPARE_* and used it for fetching /proc/[pid]/io
data as part of the procps library similar to other
fields. I moved the PROC_SPARE_* bits each by 1 bit
to retain the spare bits. Meanwhile added the IO fields
in proc_t structure.

References:
 procps-ng/procps!122
 procps-ng/procps#184
2021-04-24 22:38:48 +10:00
Issam E. Maghni
6c36ab4fc7 escape.c: Fix missing nl_langinfo on certain configs
nl_langinfo and CODESET are undefined in a musl system. Instead of
uncondionally including langinfo.h, this change includes include/nls.h
which has the tests and work-arounds for systems that don't have these
features. This is similar to how other programs within procps include
langinfo.h via nls.h

References:
 procps-ng/procps!130

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-04-24 11:46:48 +10:00
Jim Warner
c082779769 library: fix an insidious bug affecting TICS_ALL_DELTA
This simple two line code change fixes an intermittent
bug whereby %CPU for parent(s) with collapsed children
could be vastly understated from those displayed under
the current 3.3.17 publicly available top & libprocps.

If one started several top instances in the background
using very a small delay interval (zero?), then if the
shell under which they were running was collapsed, you
would see similar %CPU results for both the libraries.

However, when running a demanding 'make' like a kernel
compile (especially if backed by fast processors and a
SSD), then newlib would generally show only 1/3 to 1/2
of the collapsed %CPU values that appeared for 3.3.17.

Of course, now that the bug has been swatted with this
commit the disparities between those results is easily
explained. Since newly created tasks never contributed
tics during the interval where they were created, only
with many short lived tasks would differences surface.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-24 11:11:03 +10:00
Jim Warner
0f691226ec library: lower addr resolution cost for TICS_ALL_DELTA
Rather than run risks of more expensive and repetitive
address resolution, we will establish this local index
for a one time cost and avoid any potential gcc bloat.

[ this commit was made in pursuit of a bug involving ]
[ the distortion of elapsed task tics. but, it turns ]
[ out these changes had nothing to do with that bug. ]
[ however, the patch is being retained as desirable. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-24 11:11:03 +10:00
Jim Warner
9b601307ff library: lessen chance of distortion on TICS_ALL_DELTA
That old library defined this field as 'unsigned int'.
However, here it was known as a 'signed int'. Thus for
consistency we'll now also treat it as 'unsigned int'.

[ this commit was made in pursuit of a bug involving ]
[ the distortion of elapsed task tics. but, it turns ]
[ out these changes had nothing to do with that bug. ]
[ however, the patch is being retained as desirable. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-04-24 11:11:03 +10:00
Jim Warner
39a8c08161 library: fix a few source/origin notations, <pids> api
After removing brackets from those 'derived' notations
I was surprised to discover that several origin/source
comments were wrong. So this patch fixes those errors.

[ along the way a couple enumerators were renamed to ]
[ better (i hope) reflect what they're representing. ]

[ that, in turn, also required a little rearranging. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-03-11 21:21:23 +11:00
Jim Warner
c16c05cce5 library: clean 'derived' origins in header, <pids> api
None of the other four new api headers use brackets on
derived items. With this patch we normalize the fifth.

[ it makes for a cleaner, less confusing, appearance ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-03-11 21:21:23 +11:00
Jim Warner
add01998e4 library: tweaked key used in hash table, <meminfo> api
This small change was a result of some experimentation
trading our current 'hsearch' hash scheme for 'gperf'.

I discovered that when the ':' character was a part of
each 'gperf' key, that generated search logic was more
complicated and thus slower. But without a ':', it was
a little cleaner/leaner and therefore slightly faster.

Assuming that the same trailing ':' *might* affect the
current 'hsearch' logic, to be safe we will remove it.

[ while the 'gperf' version will slightly outperform ]
[ an 'hsearch', too many ugly implementation details ]
[ were exposed which complicates future maintenance. ]

[ thus, we'll retain our current 'hsearch' approach. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-28 21:18:26 +11:00
Jim Warner
f4e9195149 library: normalized the 'read_failed' guys across APIs
This patch will condense some logic in those functions
associated with the file input operations. The changes
will not, for the most part, alter any generated code.

More significantly (though not very) was the change to
two 'strtoul' calls. Since the returned 'endptr' value
isn't exploited, when that parm is set to NULL, we can
save one instruction on each side of such calls (wow).

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-28 21:18:26 +11:00
Jim Warner
b0bda71ac0 library: eliminate a useless conditional in readproc.h
When #define QUICK_THREADS was introduced, for copying
some task data for a child thread, one proc_t pad byte
was used to mark, then later identify, those children.

Later the QUICK_THREADS was recycled as FALSE_THREADS,
and used for a different purpose, but a conditional in
the header file erroneously remained. Now, it is gone!

Reference(s):
. Jul, 2016 - QUICK_THREADS become FALSE_THREADS
commit c546d9dd44
. Aug, 2011 - QUICK_THREADS intruduced
commit bb4f08ba29

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-23 22:07:48 +11:00
Craig Small
9aa09d8862 library: Rename to libproc-2
What to call the new library?

Keep using libprocps wouldn't do, its a very different library from
the programs' point of view. It would also mean we could have some
clashes around the packages (two package names, same library name).

The ancient procps used libproc or libproc-a.b.c where a.b.c was the
package version. Kept the revision numbers down (it was always 0.0.0)
but the name of the library changed.

So if we use libproc-2 is there a clash with an ancient procps?
procps v 2.0.0 was around in 1999 so it was 22 years ago, also the
name of the library would have been libproc-2.0.0.so not libproc-2.so
so we're fine with that.

libproc-2 seems to fit, our second major re-work of the procps
library.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 22:30:31 +11:00
Jim Warner
333a1bb6b8 library: tweak logic for /proc not mounted, <pids> api
Since 'procps_uptime' will access the /proc filesystem
the <pids> 'new' guy should should protect against the
possibility /proc isn't mounted when 'boot_seconds' is
established. A zero is better than the negative value.

[ the only distortion would be to PIDS_TIME_ELAPSED. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-18 18:35:32 +11:00
Jim Warner
0b689adde0 library: normalized 'extents_free_all' use across APIs
With the way those 'extents_free_all' guys were coded,
there's no real need to check for a NULL this->extents
before calling 'em. That's how <stat> already does it.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-18 18:35:32 +11:00
Jim Warner
fb0e4f3f68 library: update those source files for copyright dates
In addition to copyright date, the initial descriptive
line was changed from a generic statement to one which
reflects the specific portion of the proc/ filesystem.

[ such descriptions alternate between 'declarations' ]
[ (h files) & corresponding 'definitions' (c files). ]

Also, a few missing copyright attributions were added.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-09 16:40:52 +11:00
Jim Warner
3c87c46439 library: tweak 'other' user/group names for efficiency
This commit just ensures that the relatively expensive
ID to name conversions aren't performed unless they're
explicitly requested. It also internalizes those flags
that required the PROC_FILLSTATUS flag to also be set.

[ requiring a caller, in our case pids.c, to provide ]
[ two flags when a single field was the objective is ]
[ wrong & represents a future potential toe-stubber. ]

[ moreover, what's worse is that those two flags are ]
[ seemingly unrelated. but, without both, a SEGV can ]
[ can be expected when a result.str pointer is NULL. ]

[ by contrast, in the master branch those fields are ]
[ arrays which, when set to zeroes, produce an empty ]
[ string. So, there is no abend (but no name either) ]
[ when one of those two required flags were omitted. ]

[ and worth noting, in that branch it's not just one ]
[ caller required to observe a two flag requirement. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-09 16:40:52 +11:00
Craig Small
bc16fa87f0 misc: Update Craig's email 2021-01-21 17:37:48 +11:00
Jim Warner
423297c9db all: make buildable again for new 'misc.h' header file
With the 4 header files removed in the previous patch,
this commit just changes all those obsolete references
to that new consolidated 'misc.h' header file instead.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-21 17:30:25 +11:00
Jim Warner
1fdd7d4966 library: combine 4 files into new 'misc.h' header file
Prior to this patch, we had four separate header files
dealing with miscellaneous functions. Those four files
were documented in the single man page: procps_misc.3.

Now, we will have just a single header file documented
in a single man page (that is what's called symmetry).

[ and while we're at it, we will shorten that overly ]
[ long struct 'procps_namespaces' name to agree with ]
[ the function naming conventions, e.g. 'procps_ns'. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-21 17:30:24 +11:00
Jim Warner
ba9560ff02 library: reduce overhead for another 'escape' function
The preceding commit made that 'esc_all' function more
efficient by using direct pointer manipulation instead
of an indexed string reference approach within a loop.

This commit applies the same approach to the 'esc_ctl'
function. Now we'll save 12 more iterated instructions
while decreasing the function's code size by 43 bytes.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-21 17:30:24 +11:00
Jim Warner
031a08f2a7 library: improve performance for one 'escape' function
While this patch has some cosmetic whitespace changes,
more importantly it makes that 'esc_all' function more
efficient. By abandoning the indexed loop approach for
a direct pointer manipulation, we will save 9 iterated
machine instructions, for a total of 33 bytes of code.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-21 17:30:24 +11:00
Jim Warner
649e45482f library: refactor 'escape' logic for newlib (2nd time)
Much of what was represented in the commit message for
the reference shown below was revisited in this patch.
It also means that the assertion in the last paragraph
of that message will only now be true with LANG unset.

[ and forget all the bullshit about not altering any ]
[ kernel supplied data. sometimes we must to avoid a ]
[ corrupt display due to a string we can not decode. ]

And while this commit still avoids the overhead of the
'mbrtowc', 'wcwidth' 'isprint, & 'iswprint' functions,
we achieve all the benefits with simple table lookups.
Plus such benefits are extended to additional strings.

For example, both PIDS_EXE and PIDS_CMD fields are now
also subject to being 'escaped'. If a program name did
contain multibyte characters, potential truncation may
corrupt it when it's squeezed into a 15/63 byte array.

Now, all future users of this new library only need to
deal with the disparities between string and printable
lengths. Such strings themselves are always printable.

[ the ps program now contains some unnecessary costs ]
[ with the duplicated former 'escape' functions. But ]
[ we retain that copied escape.c code for posterity. ]
[ besides, in a one-shot guy it's of little concern. ]

Note: Proper display of some multibyte strings was not
possible at the linux console. It would seem a concept
of zero length chars (like a 'combining acute accent')
is not recognized. Thus the display becomes corrupted.
But if utf8 decoding is disabled (via LANG=), then all
callers will now see '?', restoring correct alignment.

Reference(s):
. Dec 2020, newlib 'escape' logic refactored
commit a221b9084a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-02 15:42:10 +11:00
Jim Warner
a221b9084a library: refactor 'escape' logic for newlib essentials
This new library provides callers with pure strings or
string vectors. It is up to those callers to deal with
potential utf8 multibyte characters and any difference
between strlen and the corresponding printable widths.

So, it makes no sense for the library to go to all the
trouble of invoking those rather expensive 'mbrtowc' &
'wcwidth' functions to ultimately yield total 'cells'.

Thus, this patch will eliminate all the code and parms
that are involved with such possible multibyte issues.

[ Along the way we'll lose the ability to substitute ]
[ '?' for an invalid/unprintable multibyte sequence. ]
[ We will, however, replace ctrl chars with the '?'. ]

[ This presents no problem for that ps program since ]
[ it now duplicates all of the original escape code. ]
[ And, we'll no longer be executing that code twice! ]

[ As for the top program, it takes the position that ]
[ it is wrong to alter kernel supplied data. So with ]
[ potential invalid/unprintable stuff, he'll rely on ]
[ terminal emulators to properly handle such issues! ]

[ Besides, even using a proper multibyte string, not ]
[ all terminals generate the proper printable width. ]
[ This is especially true when it comes to an emoji. ]

[ And should callers chose not to be portable to all ]
[ locales by calling setlocale(LC_ALL, ""), they can ]
[ expect to see lots of "?", regardless of what this ]
[ library fixes in a faulty multibyte string anyway. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-29 08:48:23 +11:00
Jim Warner
e76c773561 library: fix a potential error relating to 'exe' logic
After 'errno' management was standardized, a couple of
fields were added to the <pids> api. Only 1 (PIDS_EXE)
involved dynamic memory and, unfortunately, it did not
conform to that expected normalized ENOMEM convention.

Reference(s):
. Jun 2018, added 'exe' to library
commit ad4269f118
. Nov 2017, standardized 'errno' management
commit 06be33b43e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-29 08:48:23 +11:00
Jim Warner
fd64b91d09 library: extend ITEMTABLE_DEBUG just a tad, <PIDS> api
Under the above #define this commit now also addresses
2 additional possible toe stubbers involving 'select'.

If some readproc.h constants were uncoupled from their
pids.h enumerators a 'make check-lib' will now detect.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-29 08:48:23 +11:00
Jim Warner
07e4c08c62 misc: just a couple cosmetic changes for comments only
Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-12-29 08:48:23 +11:00
Jim Warner
eb83a1f821 library: a tweak to the UNREF_RPTHASH code, <pids> api
If a hash results report is output (via UNREF_RPTHASH)
a portion is devoted to occupied table entries ordered
by depth. There is a possibility that some depths will
not be found among existing occupied table entries and
to avoid any confusion probably should not be printed.

[ to illustrate the potential for confusion prior to ]
[ this patch, force a very small table size (like 8) ]
[ & then trigger the procps_pids_unref() eoj report. ]

So this patch ensures only 'in use' entries are shown.

[ admittedly, all of the remaining logic in the loop ]
[ could/should be subordinate to this new 'if' test, ]
[ but we will keep the change to a minimum. besides, ]
[ there's no harm subtracting/adding a zero numdepth ]
[ especially since the chance of a zero is very low. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-24 18:27:57 +11:00
Jim Warner
9eb930eebb library: tweak that history hash algorithm, <pids> api
This patch just raises the size of the hash table used
to calculate elapsed task stuff. The net result should
be less need for 'chaining' under pid hash collisions.

[ the hash scheme is intentionally kept as primitive ]
[ and, therefore, as fast as possible. it employs an ]
[ 'and' approach versus a 'mod' operation since both ]
[ yield similar distribution but the former approach ]
[ was 4 fewer cpu instructions in terms of overhead. ]

[ additionally, for hash collisions, 'chaining' uses ]
[ an array index rather than the usual pointer since ]
[ the HST_t guys may move when they are reallocated. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-11 17:53:22 +11:00
Jim Warner
e2b0f8b0af library: tweak the memory allocation logic, <pids> api
This patch separates the memory allocations into those
used initially from those used in later reallocations.
Thus, we can reduce that iterative realloc() overhead.

Additionally, we'll correct a long standing oops where
multiple history_info structures were created at 'new'
time when only one should have been allocated (jeeze).

[ originally the allocation was strangely based upon ]
[ number of 'items' (???) & later a #define constant ]

Reference(s):
. May, 2016 - subsequent bad history_info logic
commit 9ebadc1438
. Aug, 2015 - original faulty history_info code
commit 7e6a371d8a

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-11 17:53:22 +11:00
Jim Warner
ec21588be1 library: tweak those system cpu statistics, <stat> api
This patch may be a little misleading in terms of size
since most of the changes just reorder a little logic.
The most significant changes involve two GUEST values.

My original implementation excluded such tics from the
TOTAL calculation and, therefore, the BUSY figure too.

That decision was erroneously based on some code found
in ./kernel/sched/cputime.c which in hindsight applies
only to processes, not those system level cpu figures.

[ another likely oops classified STOLEN tics as IDLE ]

So, this patch attempts to bring those SUM values into
better agreement with the calculations performed for a
root cgroup (see ./kernel/cgroup/rstat.c source file).

[ we differ from those above in that we also include ]
[ the IDLE plus IOWAIT tics in our TOTAL calculation ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-13 10:00:49 +10:00
Jim Warner
bc55757231 library: eliminate unused 'FUNCTION' in private header
Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-09-13 10:00:49 +10:00
Jim Warner
2c1973d64c library: eliminate one potential source of human error
There's a huge toe-stubber awaiting future maintenance
as reflected in that commit below which deals with the
addition of new enumerators to the Item_table. Namely,
whenever the table is grown, one must remember to also
change that existing 'logical_end' enumerator's value.

Well, not anymore! Since that MAXTABLE macro was added
to the procps-private.h header we can now also exploit
it so a 'logical_end' automatically tracks table size.

This change also renders some code associated with the
ITEMTABLE_DEBUG #define unnecessary. So it's gone too.

Reference(s):
. 08/2016, add new enumerators
commit 09e1886c9e
. 08/2020, added MAXTABLE macro
commit c865b06c30
. 08/2020, introduced ITEMTABLE_DEBUG
commit 92d0297e1e

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-26 21:50:20 +10:00
Jim Warner
81db6664c9 library: fix a flaw in one 'new' function, <diskstats>
At 'new' time, the major API modules each ensure their
'info' parameter isn't NULL but what it pointed to was
except this single straggler, for some unknown reason.

So, this patch brings him into line with those others.

[ And, without going into the ugly details, this was ]
[ the reason I never experienced an abend originally ]
[ but Craig did. And, though related to stacks mgmt, ]
[ zero initialization was not a factor. Anyway, with ]
[ this patch, everybody would have experienced abend ]
[ under the original (faulty) test_Itemtables logic! ]

Reference(s):
https://www.freelists.org/post/procps/keep-on-patchin,13

Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-24 21:37:52 +10:00