Commit Graph

29 Commits

Author SHA1 Message Date
Jim Warner
220236a9af library: some minor miscellaeous improvements, 3rd gen
A collection of miscellaneous code and comment tweaks.

[ such changes will stop when desk checking ends too ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-17 08:49:48 +10:00
Jim Warner
9bea1b2def library: the overlooked twerks (oops, tweaks), 3rd gen
Yes, all of these changes are strictly cosmetic. It is
likely symptomatic of some deep-seated character flaw.

[ or, it might be because of a certain pride in this ]
[ new library and the desire to make it even better! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-09 12:48:28 +10:00
Jim Warner
a6115bfff4 library: some tweaks to 2 file read functions, 3rd gen
Ever since their introduction, plus continuing through
several evolutions, both the meminfo and vmstat 'read'
functions employed a 'do while' loop for /proc access.

However, that loop construct was wrong since identical
tests were already done (twice!) within each loop body
itself, then accompanied by its own 'break' statement.

So, we will now transform them both into forever loops
which will help us to emphasize such break statements.

[ plus, let's return an error should nothing be read ]

[ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ]

Reference(s):
. original meminfo introduction
commit a20e88e4e7
. original vmstat introduction
commit a410e236ab

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-06 21:36:37 +10:00
Jim Warner
eff9fbc06e library: standardize extents_free_all() logic, 3rd gen
As those 3rd generation newlib APIs evolved so too did
the extents_free_all() function. Most versions of this
function required the callers to first verify that the
extents anchor wasn't empty, which was poor etiquette.

This simple function should have been much more robust
and forgiving. With this commit, it fnally becomes so.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-02 16:33:01 +10:00
Jim Warner
8f1fb67a78 library: <MEMINFO> api, changed that 'get' return type
The following commit message is shared with 4 patches.
------------------------------------------------------

Under the newlib interface most of our 'get' functions
represent a bit of a compromise in that the actual raw
values are coerced into one (probably ok) return type.

That approach creates the possibility of truncation at
best, and wouldn't serve future needs should something
other than numeric data be added to the 'get' results.

This commit trades the current compromise for a return
value guaranteed to satisfy all future needs, namely a
pointer to a particular api's specific results struct.

The impact on existing programs is minimal, especially
when using a new supplied macro. Otherwise, native 'C'
syntax could be used, but may feel somewhat unnatural.

[ as an aside, this new approach allows us to delete ]
[ all 'getsfunc' table entries & the supporting code ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-21 20:58:09 +10:00
Jim Warner
4a0e974b7f library: more tweaks for code and/or comments, 3rd gen
Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.

<meminfo> ............................................
. eliminated duplicate decl of 'struct procps_meminfo'
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. how did i miss relocating all these friggin' #undefs
. cleanup 'get' return logic (remove a redundant 'if')

<pids> ...............................................
. repositioned the procps_pidsinfo structure in header
. removed the extra trailing comma from enum pids_item
. standardized/normalized results struct union members

<slabinfo> ...........................................
. corrected comment typo (jeeze, in an 'aligned' para)
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. removed an obsolete #undef from procps_slabinfo_sort
. cleanup 'get' return logic (remove a redundant 'if')

<stat> ...............................................
. how did i miss relocating all these friggin' #undefs
. corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix
. removed the extra trailing comma from enum stat_item
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. strengthen those parm checks in procps_stat_get func
. cleanup 'get' return logic (remove a redundant 'if')

<vmstat> .............................................
. standardized/normalized results struct union members
. added 'std' & 'var' dividers in .c file, like <pids>
. cleanup 'get' return logic (remove a redundant 'if')

[ virtually all of these tweaks reflect the author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 21:44:29 +10:00
Jim Warner
92c72166db library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.

[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]

[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-13 10:33:37 +10:00
Jim Warner
876ec555c3 library: final tweaks to code and/or comments, 3rd gen
With the dust now settling on all those 3rd generation
upgrades, this patch tries to provide some consistency
among the separate modules involved. Someday we should
consider a 4th generation where all redundant code has
been removed and isolated in a new shared source file.

Following is a summary of significant changes (if any)
to each of these now upgraded 3rd gen library modules.

<meminfo> ............................................
. strictly formatting/comment changes, code unaffected

<pids> ...............................................
. replaced a local mkSTR macro with existing STRINGIFY
. added fetch narrative explaining duplicate addresses

<slabinfo> ...........................................
. rearranged some free logic for procps_slabinfo_unref
. added fetch narrative explaining duplicate addresses

<stat> ...............................................
. added #define ENFORCE_LOGICAL, just as in <slabinfo>
. replaced a local mkSTR macro with existing STRINGIFY
. alphabetized the function declarations in the header

<vmstat> .............................................
. made one coverity concession with read_vmstat_failed

[ several of these changes may reflect this author's ]
[ continuing pursuit of an unreasonable goal -- that ]
[ of a 'perfect' (plus 'pretty') C language program! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-13 10:33:37 +10:00
Jim Warner
b700d91f84 library: whack a superfluous assignment, <MEMINFO> api
This patch was prompted through work on the <slabinfo>
upgrade from 2nd gen to 3rd. And while this assignment
caused no real harm, it most certainly was misleading.

[ plus add a couple of overlooked #undef directives! ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 20:51:06 +10:00
Jim Warner
af0c65900b library: add parameter checks for 'get', <MEMINFO> api
When this interface was normalized/standardized, under
the commit referenced below, the parameters were never
validated in the 'get' function. Let's plug that hole.

Reference(s):
commit 407f1b71de

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-07 21:04:43 +10:00
Jim Warner
90753e2d5b library: remove the ull_int result type, <MEMINFO> api
Because of the vast quantities of virtual memory which
may be allocated, it initially seemed like a good idea
to provide for a widest possible range through the use
of a 'ull_int' result type. However, on second thought
the implementation was a bit flawed for these reasons:

. that underlying meminfo_data variable 'VmallocTotal'
is 'unsigned long' not a required 'unsigned long long'

. there wasn't a convenient way to value it since each
variable was set with a strtoul() call, not strtoull()

So this patch will standardize on the 'ul_int' results
type (and reduce the associated delta to 's_int' too).
For now, we'll rely on protections under a 64-bit arch
where a 'ull_int' & 'ul_int' yield identical capacity.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 21:15:01 +10:00
Jim Warner
93a60022dc library: ain't like your father's delta, <MEMINFO> api
When the code for DELTA values (among other stuff) was
stolen from the recently revised <stat> interface, the
concept of ever growing values was propagated too. But
here we must manage both growing and shrinking values.

Thus former protections against a negative delta don't
have any place in this module and are hereby banished.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 21:13:47 +10:00
Craig Small
b4beb162fd library: minor fix for procps_meminfo_select
Thus function returns a pointer, not an int, so if there is
an error return NULL and not -errno.

proc/meminfo.c: In function ‘procps_meminfo_select’:
proc/meminfo.c:994:20: warning: return makes pointer from integer
without a cast [-Wint-conversion]
             return -ENOMEM;

References:
 commit 407f1b71de
2016-05-12 07:52:36 +10:00
Jim Warner
407f1b71de library: improve/normalize an interface, <MEMINFO> api
This represents the refinement of this interface after
the <stat> API was redesigned. We now follow a pattern
of 'get' for single item retrieval & 'select' for when
multiple items are desired, with just 1 function call.

And again following the <stat> lead this interface now
provides for delta values encompassing most items. The
reason I went cuckoo nuts with those deltas is because
they are essentially free. At the cost of a little RAM
and just one memcpy there's no other price to be paid.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 07:51:10 +10:00
Craig Small
602b9a02ce free: use SReclaimable in cached
The previous commit added all of slab into the cache value. The
thing was is cached in this context is something you can get
back and reclaim if under memory pressure.

The problem was slab parameter includes both reclaimable and
unreclaimable values which doesn't make sense in this context.
This commit make cached only use the reclaimable component.

References:
 http://www.freelists.org/post/procps/OmegaPhilxxxxxxxxxxxxx-Bug799716-free-considers-cached-to-include-SUnreclaim
 https://github.com/brndnmtthws/conky/issues/130
 https://bugs.debian.org/799716

Commits:
 05d751c4f0
 6cb75efef8
2015-10-24 14:29:25 +11:00
Jim Warner
836c134579 library: with valgrind help, fix faulty meminfo assign
Not sure how this one has gone unnoticed until now but
with valgrind's help it's going bye-bye lickety-split.

Reference(s):
==26533== Conditional jump or move depends on uninitialised value(s)
==26533==    at 0x4E4082B: procps_meminfo_stack_fill (meminfo.c:408)

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-09-21 22:35:05 +10:00
Jim Warner
63e828fe88 library: minor tweaks of program logic and/or comments
This commit just corrects the oversight wherein 'item'
was being employed when 'these' was actually intended.

Also, it trades some 'item' use for a more descriptive
input parameter which henceforth is known as a 'dest'.

And, there was one leftover 'next' pointer eliminated.

Finally, some logic was made a tad less dependent upon
enumerator names and a few comments were also updated.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-28 21:51:00 +10:00
Jim Warner
ae4b686745 library: eliminate extra stack header space provisions
With the new perspective on potential uses of a 'noop'
enumerator (or whatever we decide to call it) there is
no longer a need to provide for any extra 'user' space
in the stack header structures used by slab & meminfo.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-23 22:31:50 +10:00
Jim Warner
b8c688fb36 library: meminfo redesigned to use 'stack' vs. 'chain'
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>
2015-07-23 22:31:24 +10:00
Jim Warner
74cb6afcc9 library: tweak new interface code and improve comments
With a little help from smatch, this commit eliminates
some inappropriate code. Also some programmer comments
were (barely) improved (i hope) in some small measure.

Reference(s):
smatch: 406 procps_meminfo_chain_fill() warn: variable dereferenced before check 'chain' (see line 403)

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-15 21:25:09 +10:00
Jim Warner
aab537bc13 library: refactor meminfo providing dynamic allocation
An earlier approach to meminfo chaining, referenced in
the patch shown below, represents the first baby steps
toward the goal of some generalized approach with PIDs
processing. However, statically allocating a chain for
each task or thread is totally impractical. And, while
a single chain could serve all PIDs, that would mean a
separate call to our library for each running process.

This commit is intended as the next evolutionary step,
dynamically allocating some 'result' chains to contain
as many or as few 'items' as a caller wishes. In other
words, holding only those 'items' of current interest.

This is the kind of service useful for both top and ps
programs if we finally get around to /proc/<PID> data.

Reference(s):
commit c3fd7473c5

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-14 22:32:41 +10:00
Jim Warner
faf6d4dc93 library: the uref functions were insufficiently robust
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>
2015-07-01 21:30:17 +10:00
Jim Warner
74beff80ff library: make reads & unref logic a little more robust
Since we are not using a higher level standard C fopen
all of the read requests were made signal sensitive as
that can result in a 'temporarily' failed i/o request.

Also, protection against some user calling the 'unref'
function on already free memory has been incorporated.
This will protect us from some nasty 'Abort' surprise.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-29 21:30:48 +10:00
Jim Warner
a05084f381 library: add chaining provisions to meminfo and vmstat
If a caller chooses to reduce the overhead of repeated
function calls, this commit provides for acquiring all
the desired information in just a single library call.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-29 21:29:29 +10:00
Jim Warner
7a98cab187 library: add missing meminfo logic, improve efficiency
This patch fills in some missing fields which have top
dependencies. Additionally, I've tried to mirror those
calculations Jaromir added for release 3.3.10. The one
calculation that remains missing is 'available' memory
for some kernels. For this API, we'll use a fall-back.

Lastly the lxc safeguards which were recently added to
the old procps library were incorporated here as well.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-29 21:29:24 +10:00
Jim Warner
500a901475 library: tweak formatting style for meminfo and vmstat
This patch mostly just eliminates darn tab characters.

Plus the library function declarations and definitions
have been standardized. Most visibly, the input params
now have all been indented on their own separate line.

Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-29 21:29:19 +10:00
Craig Small
05efbebb66 library: Fix up stat API
Adjusted vmstat to use the new API for memory and CPU statistics
2015-06-26 22:37:28 +10:00
Craig Small
ca4a09c432 library: memory and vmstat API changes
Created new set of functions for meminfo related calls. Liked the
format of that better so changed vmstat around so the look similar.
Missed the makefile change for uptime so added it in now.
2015-06-26 22:37:28 +10:00
Craig Small
a20e88e4e7 library: Add procps_meminfo_* functions
New set of functions that read the /proc/meminfo file. Still needs
work.
2015-06-26 22:37:28 +10:00