2015-06-21 13:52:28 +05:30
|
|
|
/*
|
2021-02-05 11:30:00 +05:30
|
|
|
* meminfo.c - memory related definitions for libprocps
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2015 Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
* Copyright (C) 2016-2021 Jim Warner <james.warner@comcast.net>
|
2015-06-21 13:52:28 +05:30
|
|
|
*
|
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
|
*/
|
2015-07-21 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <errno.h>
|
2015-07-21 10:30:00 +05:30
|
|
|
#include <fcntl.h>
|
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-10 10:30:00 +05:30
|
|
|
#include <search.h>
|
2016-05-11 22:30:00 +05:30
|
|
|
#include <stdio.h>
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
2016-05-11 22:30:00 +05:30
|
|
|
#include <time.h>
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <unistd.h>
|
2015-07-21 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <sys/stat.h>
|
2015-07-21 10:30:00 +05:30
|
|
|
#include <sys/types.h>
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
#include <proc/procps-private.h>
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <proc/meminfo.h>
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2020-06-29 10:30:00 +05:30
|
|
|
#define MEMINFO_FILE "/proc/meminfo"
|
|
|
|
|
#define MEMINFO_BUFF 8192
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2020-08-10 10:30:00 +05:30
|
|
|
/* ------------------------------------------------------------------------- +
|
|
|
|
|
this provision can be used to ensure that our Item_table was synchronized |
|
|
|
|
|
with those enumerators found in the associated header file. It's intended |
|
|
|
|
|
to only be used locally (& temporarily) at some point prior to a release! | */
|
|
|
|
|
// #define ITEMTABLE_DEBUG //----------------------------------------------- |
|
|
|
|
|
// ------------------------------------------------------------------------- +
|
|
|
|
|
|
2016-06-09 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
struct meminfo_data {
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Active;
|
2018-12-01 11:30:00 +05:30
|
|
|
unsigned long Active_anon; // as: Active(anon): man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long Active_file; // as: Active(file): man 5 proc: 'to be documented'
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long AnonHugePages;
|
|
|
|
|
unsigned long AnonPages;
|
|
|
|
|
unsigned long Bounce;
|
|
|
|
|
unsigned long Buffers;
|
|
|
|
|
unsigned long Cached;
|
2018-12-01 11:30:00 +05:30
|
|
|
unsigned long CmaFree;
|
|
|
|
|
unsigned long CmaTotal;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long CommitLimit;
|
|
|
|
|
unsigned long Committed_AS;
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
unsigned long DirectMap1G;
|
|
|
|
|
unsigned long DirectMap2M;
|
|
|
|
|
unsigned long DirectMap4M;
|
|
|
|
|
unsigned long DirectMap4k;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Dirty;
|
2020-08-07 10:30:00 +05:30
|
|
|
unsigned long FileHugePages;
|
|
|
|
|
unsigned long FilePmdMapped;
|
2018-12-01 11:30:00 +05:30
|
|
|
unsigned long HardwareCorrupted; // man 5 proc: 'to be documented'
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long HighFree;
|
|
|
|
|
unsigned long HighTotal;
|
|
|
|
|
unsigned long HugePages_Free;
|
|
|
|
|
unsigned long HugePages_Rsvd;
|
|
|
|
|
unsigned long HugePages_Surp;
|
|
|
|
|
unsigned long HugePages_Total;
|
|
|
|
|
unsigned long Hugepagesize;
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
unsigned long Hugetlb;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Inactive;
|
2018-12-01 11:30:00 +05:30
|
|
|
unsigned long Inactive_anon; // as: Inactive(anon): man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long Inactive_file; // as: Inactive(file): man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long KReclaimable;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long KernelStack;
|
|
|
|
|
unsigned long LowFree;
|
|
|
|
|
unsigned long LowTotal;
|
|
|
|
|
unsigned long Mapped;
|
|
|
|
|
unsigned long MemAvailable;
|
|
|
|
|
unsigned long MemFree;
|
|
|
|
|
unsigned long MemTotal;
|
2018-12-01 11:30:00 +05:30
|
|
|
unsigned long Mlocked; // man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long MmapCopy; // man 5 proc: 'to be documented'
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long NFS_Unstable;
|
|
|
|
|
unsigned long PageTables;
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
unsigned long Percpu;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long SReclaimable;
|
|
|
|
|
unsigned long SUnreclaim;
|
2020-08-07 10:30:00 +05:30
|
|
|
unsigned long ShadowCallStack;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Shmem;
|
2016-08-11 21:41:11 +05:30
|
|
|
unsigned long ShmemHugePages;
|
|
|
|
|
unsigned long ShmemPmdMapped;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Slab;
|
|
|
|
|
unsigned long SwapCached;
|
|
|
|
|
unsigned long SwapFree;
|
|
|
|
|
unsigned long SwapTotal;
|
2018-12-01 11:30:00 +05:30
|
|
|
unsigned long Unevictable; // man 5 proc: 'to be documented'
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long VmallocChunk;
|
|
|
|
|
unsigned long VmallocTotal;
|
|
|
|
|
unsigned long VmallocUsed;
|
|
|
|
|
unsigned long Writeback;
|
|
|
|
|
unsigned long WritebackTmp;
|
|
|
|
|
|
2017-05-29 11:41:11 +05:30
|
|
|
unsigned long derived_mem_cached;
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long derived_mem_hi_used;
|
|
|
|
|
unsigned long derived_mem_lo_used;
|
|
|
|
|
unsigned long derived_mem_used;
|
|
|
|
|
unsigned long derived_swap_used;
|
|
|
|
|
};
|
|
|
|
|
|
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-10 10:30:00 +05:30
|
|
|
struct mem_hist {
|
2016-05-11 22:30:00 +05:30
|
|
|
struct meminfo_data new;
|
|
|
|
|
struct meminfo_data old;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct stacks_extent {
|
|
|
|
|
int ext_numstacks;
|
|
|
|
|
struct stacks_extent *next;
|
|
|
|
|
struct meminfo_stack **stacks;
|
2015-06-20 18:38:47 +05:30
|
|
|
};
|
|
|
|
|
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info {
|
2015-06-20 18:38:47 +05:30
|
|
|
int refcount;
|
|
|
|
|
int meminfo_fd;
|
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-10 10:30:00 +05:30
|
|
|
struct mem_hist hist;
|
2016-05-11 22:30:00 +05:30
|
|
|
int numitems;
|
|
|
|
|
enum meminfo_item *items;
|
|
|
|
|
struct stacks_extent *extents;
|
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-10 10:30:00 +05:30
|
|
|
struct hsearch_data hashtab;
|
2016-06-18 10:30:00 +05:30
|
|
|
struct meminfo_result get_this;
|
2015-07-11 10:30:00 +05:30
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
#define setNAME(e) set_meminfo_ ## e
|
2016-05-11 22:30:00 +05:30
|
|
|
#define setDECL(e) static void setNAME(e) \
|
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-10 10:30:00 +05:30
|
|
|
(struct meminfo_result *R, struct mem_hist *H)
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
// regular assignment
|
2019-12-12 10:30:00 +05:30
|
|
|
#define MEM_set(e,t,x) setDECL(e) { R->result. t = H->new. x; }
|
2016-05-11 22:30:00 +05:30
|
|
|
// delta assignment
|
2019-12-12 10:30:00 +05:30
|
|
|
#define HST_set(e,t,x) setDECL(e) { R->result. t = ( H->new. x - H->old. x ); }
|
2016-05-11 22:30:00 +05:30
|
|
|
|
library: minimize the use of 'cleanup_stacks' routines
Some parts of our newlib implementation are the result
of functions which have been propagated from module to
module. In particular, those 'cleanup_stacks' routines
are all similar & likely originated in the <pids> api.
In that interface there was a need to free dynamically
acquired memory before the result structure was reused
to satisfy subsequent 'get', 'select' or 'reap' calls.
This, in turn, led to a concept of 'dirty' stacks with
the need to call one of two 'cleanup_stack' functions.
None of the remaining interfaces deal with such memory
yet they each had their own 'cleanup_stack' functions.
Those functions were responsible for resetting each of
the result unions to zero, excluding any 'noop' items.
The bottom line is that for all interfaces, repetitive
calls would require iterating through the stack(s) two
separate times: once to 'cleanup' another to 'assign'.
With this commit we will reduce iterations to just the
'assign' routine. A reset to zero will be accomplished
in the 'extra' item set routine (which is the only one
actually requiring any reset). All other items will be
reinitialized automatically by a new current set value
or upon reallocation when an items compliment changes.
In the <pids> interface, any freeing of dynamic memory
could have been accomplished by adding that 'freefunc'
check to the 'assign' function. However, that requires
an Item_table test with every item. Instead, we'll now
satisfy such needs as the very first step in those set
functions responsible for dynamically acquired memory.
[ the <pids> api retains 2 'cleanup_stack' functions ]
[ to accommodate stack(s) 'reset' & to serve 'unref' ]
Lastly, all the 'itemize_stack' functions were tweaked
by eliminating an unnecessary initialization of result
unions. That objective was already accomplished by the
calloc() in a 'stacks_alloc' function or the remaining
'cleanup_stack' routine found in the <pids> interface.
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
|
|
|
setDECL(noop) { (void)R; (void)H; }
|
|
|
|
|
setDECL(extra) { (void)H; R->result.ul_int = 0; }
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
MEM_set(MEM_ACTIVE, ul_int, Active)
|
|
|
|
|
MEM_set(MEM_ACTIVE_ANON, ul_int, Active_anon)
|
|
|
|
|
MEM_set(MEM_ACTIVE_FILE, ul_int, Active_file)
|
|
|
|
|
MEM_set(MEM_ANON, ul_int, AnonPages)
|
|
|
|
|
MEM_set(MEM_AVAILABLE, ul_int, MemAvailable)
|
|
|
|
|
MEM_set(MEM_BOUNCE, ul_int, Bounce)
|
|
|
|
|
MEM_set(MEM_BUFFERS, ul_int, Buffers)
|
|
|
|
|
MEM_set(MEM_CACHED, ul_int, Cached)
|
2017-05-29 11:41:11 +05:30
|
|
|
MEM_set(MEM_CACHED_ALL, ul_int, derived_mem_cached)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
MEM_set(MEM_CMA_FREE, ul_int, CmaFree)
|
|
|
|
|
MEM_set(MEM_CMA_TOTAL, ul_int, CmaTotal)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_COMMITTED_AS, ul_int, Committed_AS)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
MEM_set(MEM_COMMIT_LIMIT, ul_int, CommitLimit)
|
|
|
|
|
MEM_set(MEM_DIRECTMAP_1G, ul_int, DirectMap1G)
|
|
|
|
|
MEM_set(MEM_DIRECTMAP_2M, ul_int, DirectMap2M)
|
|
|
|
|
MEM_set(MEM_DIRECTMAP_4K, ul_int, DirectMap4k)
|
|
|
|
|
MEM_set(MEM_DIRECTMAP_4M, ul_int, DirectMap4M)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_DIRTY, ul_int, Dirty)
|
2020-08-07 10:30:00 +05:30
|
|
|
MEM_set(MEM_FILE_HUGEPAGES, ul_int, FileHugePages)
|
|
|
|
|
MEM_set(MEM_FILE_PMDMAPPED, ul_int, FilePmdMapped)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_FREE, ul_int, MemFree)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
MEM_set(MEM_HARD_CORRUPTED, ul_int, HardwareCorrupted)
|
|
|
|
|
MEM_set(MEM_HIGH_FREE, ul_int, HighFree)
|
|
|
|
|
MEM_set(MEM_HIGH_TOTAL, ul_int, HighTotal)
|
|
|
|
|
MEM_set(MEM_HIGH_USED, ul_int, derived_mem_hi_used)
|
|
|
|
|
MEM_set(MEM_HUGETBL, ul_int, Hugetlb)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_HUGE_ANON, ul_int, AnonHugePages)
|
|
|
|
|
MEM_set(MEM_HUGE_FREE, ul_int, HugePages_Free)
|
|
|
|
|
MEM_set(MEM_HUGE_RSVD, ul_int, HugePages_Rsvd)
|
|
|
|
|
MEM_set(MEM_HUGE_SIZE, ul_int, Hugepagesize)
|
|
|
|
|
MEM_set(MEM_HUGE_SURPLUS, ul_int, HugePages_Surp)
|
|
|
|
|
MEM_set(MEM_HUGE_TOTAL, ul_int, HugePages_Total)
|
|
|
|
|
MEM_set(MEM_INACTIVE, ul_int, Inactive)
|
|
|
|
|
MEM_set(MEM_INACTIVE_ANON, ul_int, Inactive_anon)
|
|
|
|
|
MEM_set(MEM_INACTIVE_FILE, ul_int, Inactive_file)
|
2018-12-01 11:30:00 +05:30
|
|
|
MEM_set(MEM_KERNEL_RECLAIM, ul_int, KReclaimable)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_KERNEL_STACK, ul_int, KernelStack)
|
|
|
|
|
MEM_set(MEM_LOCKED, ul_int, Mlocked)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
MEM_set(MEM_LOW_FREE, ul_int, LowFree)
|
|
|
|
|
MEM_set(MEM_LOW_TOTAL, ul_int, LowTotal)
|
|
|
|
|
MEM_set(MEM_LOW_USED, ul_int, derived_mem_lo_used)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_MAPPED, ul_int, Mapped)
|
2018-12-01 11:30:00 +05:30
|
|
|
MEM_set(MEM_MAP_COPY, ul_int, MmapCopy)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_NFS_UNSTABLE, ul_int, NFS_Unstable)
|
|
|
|
|
MEM_set(MEM_PAGE_TABLES, ul_int, PageTables)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
MEM_set(MEM_PER_CPU, ul_int, Percpu)
|
2020-08-07 10:30:00 +05:30
|
|
|
MEM_set(MEM_SHADOWCALLSTACK, ul_int, ShadowCallStack)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_SHARED, ul_int, Shmem)
|
2016-08-11 21:41:11 +05:30
|
|
|
MEM_set(MEM_SHMEM_HUGE, ul_int, ShmemHugePages)
|
|
|
|
|
MEM_set(MEM_SHMEM_HUGE_MAP, ul_int, ShmemPmdMapped)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_SLAB, ul_int, Slab)
|
|
|
|
|
MEM_set(MEM_SLAB_RECLAIM, ul_int, SReclaimable)
|
|
|
|
|
MEM_set(MEM_SLAB_UNRECLAIM, ul_int, SUnreclaim)
|
|
|
|
|
MEM_set(MEM_TOTAL, ul_int, MemTotal)
|
|
|
|
|
MEM_set(MEM_UNEVICTABLE, ul_int, Unevictable)
|
|
|
|
|
MEM_set(MEM_USED, ul_int, derived_mem_used)
|
|
|
|
|
MEM_set(MEM_VM_ALLOC_CHUNK, ul_int, VmallocChunk)
|
2016-05-12 10:30:00 +05:30
|
|
|
MEM_set(MEM_VM_ALLOC_TOTAL, ul_int, VmallocTotal)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_VM_ALLOC_USED, ul_int, VmallocUsed)
|
|
|
|
|
MEM_set(MEM_WRITEBACK, ul_int, Writeback)
|
|
|
|
|
MEM_set(MEM_WRITEBACK_TMP, ul_int, WritebackTmp)
|
|
|
|
|
|
|
|
|
|
HST_set(DELTA_ACTIVE, s_int, Active)
|
|
|
|
|
HST_set(DELTA_ACTIVE_ANON, s_int, Active_anon)
|
|
|
|
|
HST_set(DELTA_ACTIVE_FILE, s_int, Active_file)
|
|
|
|
|
HST_set(DELTA_ANON, s_int, AnonPages)
|
|
|
|
|
HST_set(DELTA_AVAILABLE, s_int, MemAvailable)
|
|
|
|
|
HST_set(DELTA_BOUNCE, s_int, Bounce)
|
|
|
|
|
HST_set(DELTA_BUFFERS, s_int, Buffers)
|
|
|
|
|
HST_set(DELTA_CACHED, s_int, Cached)
|
2017-05-29 11:41:11 +05:30
|
|
|
HST_set(DELTA_CACHED_ALL, s_int, derived_mem_cached)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
HST_set(DELTA_CMA_FREE, s_int, CmaFree)
|
|
|
|
|
HST_set(DELTA_CMA_TOTAL, s_int, CmaTotal)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_COMMITTED_AS, s_int, Committed_AS)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
HST_set(DELTA_COMMIT_LIMIT, s_int, CommitLimit)
|
|
|
|
|
HST_set(DELTA_DIRECTMAP_1G, s_int, DirectMap1G)
|
|
|
|
|
HST_set(DELTA_DIRECTMAP_2M, s_int, DirectMap2M)
|
|
|
|
|
HST_set(DELTA_DIRECTMAP_4K, s_int, DirectMap4k)
|
|
|
|
|
HST_set(DELTA_DIRECTMAP_4M, s_int, DirectMap4M)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_DIRTY, s_int, Dirty)
|
2020-08-07 10:30:00 +05:30
|
|
|
HST_set(DELTA_FILE_HUGEPAGES, s_int, FileHugePages)
|
|
|
|
|
HST_set(DELTA_FILE_PMDMAPPED, s_int, FilePmdMapped)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_FREE, s_int, MemFree)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
HST_set(DELTA_HARD_CORRUPTED, s_int, HardwareCorrupted)
|
|
|
|
|
HST_set(DELTA_HIGH_FREE, s_int, HighFree)
|
|
|
|
|
HST_set(DELTA_HIGH_TOTAL, s_int, HighTotal)
|
|
|
|
|
HST_set(DELTA_HIGH_USED, s_int, derived_mem_hi_used)
|
|
|
|
|
HST_set(DELTA_HUGETBL, s_int, Hugetlb)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_HUGE_ANON, s_int, AnonHugePages)
|
|
|
|
|
HST_set(DELTA_HUGE_FREE, s_int, HugePages_Free)
|
|
|
|
|
HST_set(DELTA_HUGE_RSVD, s_int, HugePages_Rsvd)
|
|
|
|
|
HST_set(DELTA_HUGE_SIZE, s_int, Hugepagesize)
|
|
|
|
|
HST_set(DELTA_HUGE_SURPLUS, s_int, HugePages_Surp)
|
|
|
|
|
HST_set(DELTA_HUGE_TOTAL, s_int, HugePages_Total)
|
|
|
|
|
HST_set(DELTA_INACTIVE, s_int, Inactive)
|
|
|
|
|
HST_set(DELTA_INACTIVE_ANON, s_int, Inactive_anon)
|
|
|
|
|
HST_set(DELTA_INACTIVE_FILE, s_int, Inactive_file)
|
2018-12-01 11:30:00 +05:30
|
|
|
HST_set(DELTA_KERNEL_RECLAIM, s_int, KReclaimable)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_KERNEL_STACK, s_int, KernelStack)
|
|
|
|
|
HST_set(DELTA_LOCKED, s_int, Mlocked)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
HST_set(DELTA_LOW_FREE, s_int, LowFree)
|
|
|
|
|
HST_set(DELTA_LOW_TOTAL, s_int, LowTotal)
|
|
|
|
|
HST_set(DELTA_LOW_USED, s_int, derived_mem_lo_used)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_MAPPED, s_int, Mapped)
|
2018-12-01 11:30:00 +05:30
|
|
|
HST_set(DELTA_MAP_COPY, s_int, MmapCopy)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_NFS_UNSTABLE, s_int, NFS_Unstable)
|
|
|
|
|
HST_set(DELTA_PAGE_TABLES, s_int, PageTables)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
HST_set(DELTA_PER_CPU, s_int, Percpu)
|
2020-08-07 10:30:00 +05:30
|
|
|
HST_set(DELTA_SHADOWCALLSTACK, s_int, ShadowCallStack)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_SHARED, s_int, Shmem)
|
2016-08-11 21:41:11 +05:30
|
|
|
HST_set(DELTA_SHMEM_HUGE, s_int, ShmemHugePages)
|
|
|
|
|
HST_set(DELTA_SHMEM_HUGE_MAP, s_int, ShmemPmdMapped)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_SLAB, s_int, Slab)
|
|
|
|
|
HST_set(DELTA_SLAB_RECLAIM, s_int, SReclaimable)
|
|
|
|
|
HST_set(DELTA_SLAB_UNRECLAIM, s_int, SUnreclaim)
|
|
|
|
|
HST_set(DELTA_TOTAL, s_int, MemTotal)
|
|
|
|
|
HST_set(DELTA_UNEVICTABLE, s_int, Unevictable)
|
|
|
|
|
HST_set(DELTA_USED, s_int, derived_mem_used)
|
|
|
|
|
HST_set(DELTA_VM_ALLOC_CHUNK, s_int, VmallocChunk)
|
2016-05-12 10:30:00 +05:30
|
|
|
HST_set(DELTA_VM_ALLOC_TOTAL, s_int, VmallocTotal)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_VM_ALLOC_USED, s_int, VmallocUsed)
|
|
|
|
|
HST_set(DELTA_WRITEBACK, s_int, Writeback)
|
|
|
|
|
HST_set(DELTA_WRITEBACK_TMP, s_int, WritebackTmp)
|
|
|
|
|
|
|
|
|
|
MEM_set(SWAP_CACHED, ul_int, SwapCached)
|
|
|
|
|
MEM_set(SWAP_FREE, ul_int, SwapFree)
|
|
|
|
|
MEM_set(SWAP_TOTAL, ul_int, SwapTotal)
|
|
|
|
|
MEM_set(SWAP_USED, ul_int, derived_swap_used)
|
|
|
|
|
|
2017-09-07 10:30:00 +05:30
|
|
|
HST_set(SWAP_DELTA_CACHED, s_int, SwapCached)
|
|
|
|
|
HST_set(SWAP_DELTA_FREE, s_int, SwapFree)
|
|
|
|
|
HST_set(SWAP_DELTA_TOTAL, s_int, SwapTotal)
|
|
|
|
|
HST_set(SWAP_DELTA_USED, s_int, derived_swap_used)
|
|
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
#undef setDECL
|
|
|
|
|
#undef MEM_set
|
|
|
|
|
#undef HST_set
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
// ___ Controlling Table ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
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-10 10:30:00 +05:30
|
|
|
typedef void (*SET_t)(struct meminfo_result *, struct mem_hist *);
|
2020-08-10 10:30:00 +05:30
|
|
|
#ifdef ITEMTABLE_DEBUG
|
|
|
|
|
#define RS(e) (SET_t)setNAME(e), MEMINFO_ ## e, STRINGIFY(MEMINFO_ ## e)
|
|
|
|
|
#else
|
2016-05-11 22:30:00 +05:30
|
|
|
#define RS(e) (SET_t)setNAME(e)
|
2020-08-10 10:30:00 +05:30
|
|
|
#endif
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2016-08-05 10:30:00 +05:30
|
|
|
#define TS(t) STRINGIFY(t)
|
|
|
|
|
#define TS_noop ""
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/*
|
|
|
|
|
* Need it be said?
|
|
|
|
|
* This table must be kept in the exact same order as
|
|
|
|
|
* those 'enum meminfo_item' guys ! */
|
|
|
|
|
static struct {
|
|
|
|
|
SET_t setsfunc; // the actual result setting routine
|
2020-08-10 10:30:00 +05:30
|
|
|
#ifdef ITEMTABLE_DEBUG
|
|
|
|
|
int enumnumb; // enumerator (must match position!)
|
|
|
|
|
char *enum2str; // enumerator name as a char* string
|
|
|
|
|
#endif
|
2016-08-05 10:30:00 +05:30
|
|
|
char *type2str; // the result type as a string value
|
2016-05-11 22:30:00 +05:30
|
|
|
} Item_table[] = {
|
2016-08-05 10:30:00 +05:30
|
|
|
/* setsfunc type2str
|
|
|
|
|
------------------------- ---------- */
|
|
|
|
|
{ RS(noop), TS_noop },
|
|
|
|
|
{ RS(extra), TS_noop },
|
|
|
|
|
|
|
|
|
|
{ RS(MEM_ACTIVE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_ACTIVE_ANON), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_ACTIVE_FILE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_ANON), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_AVAILABLE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_BOUNCE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_BUFFERS), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_CACHED), TS(ul_int) },
|
2017-05-29 11:41:11 +05:30
|
|
|
{ RS(MEM_CACHED_ALL), TS(ul_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(MEM_CMA_FREE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_CMA_TOTAL), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_COMMITTED_AS), TS(ul_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(MEM_COMMIT_LIMIT), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_DIRECTMAP_1G), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_DIRECTMAP_2M), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_DIRECTMAP_4K), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_DIRECTMAP_4M), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_DIRTY), TS(ul_int) },
|
2020-08-07 10:30:00 +05:30
|
|
|
{ RS(MEM_FILE_HUGEPAGES), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_FILE_PMDMAPPED), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_FREE), TS(ul_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(MEM_HARD_CORRUPTED), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HIGH_FREE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HIGH_TOTAL), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HIGH_USED), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HUGETBL), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_HUGE_ANON), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HUGE_FREE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HUGE_RSVD), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HUGE_SIZE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HUGE_SURPLUS), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_HUGE_TOTAL), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_INACTIVE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_INACTIVE_ANON), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_INACTIVE_FILE), TS(ul_int) },
|
2018-12-01 11:30:00 +05:30
|
|
|
{ RS(MEM_KERNEL_RECLAIM), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_KERNEL_STACK), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_LOCKED), TS(ul_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(MEM_LOW_FREE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_LOW_TOTAL), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_LOW_USED), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_MAPPED), TS(ul_int) },
|
2018-12-01 11:30:00 +05:30
|
|
|
{ RS(MEM_MAP_COPY), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_NFS_UNSTABLE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_PAGE_TABLES), TS(ul_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(MEM_PER_CPU), TS(ul_int) },
|
2020-08-07 10:30:00 +05:30
|
|
|
{ RS(MEM_SHADOWCALLSTACK), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_SHARED), TS(ul_int) },
|
2016-08-11 21:41:11 +05:30
|
|
|
{ RS(MEM_SHMEM_HUGE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_SHMEM_HUGE_MAP), TS(ul_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(MEM_SLAB), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_SLAB_RECLAIM), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_SLAB_UNRECLAIM), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_TOTAL), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_UNEVICTABLE), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_USED), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_VM_ALLOC_CHUNK), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_VM_ALLOC_TOTAL), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_VM_ALLOC_USED), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_WRITEBACK), TS(ul_int) },
|
|
|
|
|
{ RS(MEM_WRITEBACK_TMP), TS(ul_int) },
|
|
|
|
|
|
|
|
|
|
{ RS(DELTA_ACTIVE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_ACTIVE_ANON), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_ACTIVE_FILE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_ANON), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_AVAILABLE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_BOUNCE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_BUFFERS), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_CACHED), TS(s_int) },
|
2017-05-29 11:41:11 +05:30
|
|
|
{ RS(DELTA_CACHED_ALL), TS(s_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(DELTA_CMA_FREE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_CMA_TOTAL), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_COMMITTED_AS), TS(s_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(DELTA_COMMIT_LIMIT), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_DIRECTMAP_1G), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_DIRECTMAP_2M), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_DIRECTMAP_4K), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_DIRECTMAP_4M), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_DIRTY), TS(s_int) },
|
2020-08-07 10:30:00 +05:30
|
|
|
{ RS(DELTA_FILE_HUGEPAGES), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_FILE_PMDMAPPED), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_FREE), TS(s_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(DELTA_HARD_CORRUPTED), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HIGH_FREE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HIGH_TOTAL), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HIGH_USED), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HUGETBL), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_HUGE_ANON), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HUGE_FREE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HUGE_RSVD), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HUGE_SIZE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HUGE_SURPLUS), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_HUGE_TOTAL), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_INACTIVE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_INACTIVE_ANON), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_INACTIVE_FILE), TS(s_int) },
|
2018-12-01 11:30:00 +05:30
|
|
|
{ RS(DELTA_KERNEL_RECLAIM), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_KERNEL_STACK), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_LOCKED), TS(s_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(DELTA_LOW_FREE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_LOW_TOTAL), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_LOW_USED), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_MAPPED), TS(s_int) },
|
2018-12-01 11:30:00 +05:30
|
|
|
{ RS(DELTA_MAP_COPY), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_NFS_UNSTABLE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_PAGE_TABLES), TS(s_int) },
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
{ RS(DELTA_PER_CPU), TS(s_int) },
|
2020-08-07 10:30:00 +05:30
|
|
|
{ RS(DELTA_SHADOWCALLSTACK), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_SHARED), TS(s_int) },
|
2016-08-11 21:41:11 +05:30
|
|
|
{ RS(DELTA_SHMEM_HUGE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_SHMEM_HUGE_MAP), TS(s_int) },
|
2016-08-05 10:30:00 +05:30
|
|
|
{ RS(DELTA_SLAB), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_SLAB_RECLAIM), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_SLAB_UNRECLAIM), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_TOTAL), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_UNEVICTABLE), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_USED), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_VM_ALLOC_CHUNK), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_VM_ALLOC_TOTAL), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_VM_ALLOC_USED), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_WRITEBACK), TS(s_int) },
|
|
|
|
|
{ RS(DELTA_WRITEBACK_TMP), TS(s_int) },
|
|
|
|
|
|
|
|
|
|
{ RS(SWAP_CACHED), TS(ul_int) },
|
|
|
|
|
{ RS(SWAP_FREE), TS(ul_int) },
|
|
|
|
|
{ RS(SWAP_TOTAL), TS(ul_int) },
|
|
|
|
|
{ RS(SWAP_USED), TS(ul_int) },
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2017-09-07 10:30:00 +05:30
|
|
|
{ RS(SWAP_DELTA_CACHED), TS(s_int) },
|
|
|
|
|
{ RS(SWAP_DELTA_FREE), TS(s_int) },
|
|
|
|
|
{ RS(SWAP_DELTA_TOTAL), TS(s_int) },
|
|
|
|
|
{ RS(SWAP_DELTA_USED), TS(s_int) },
|
2015-06-20 18:38:47 +05:30
|
|
|
};
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* please note,
|
|
|
|
|
* this enum MUST be 1 greater than the highest value of any enum */
|
2020-08-22 10:30:00 +05:30
|
|
|
enum meminfo_item MEMINFO_logical_end = MAXTABLE(Item_table);
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
#undef setNAME
|
2016-06-06 10:30:00 +05:30
|
|
|
#undef RS
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
static inline void meminfo_assign_results (
|
2016-05-11 22:30:00 +05:30
|
|
|
struct meminfo_stack *stack,
|
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-10 10:30:00 +05:30
|
|
|
struct mem_hist *hist)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
2016-05-11 22:30:00 +05:30
|
|
|
struct meminfo_result *this = stack->head;
|
|
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
enum meminfo_item item = this->item;
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
if (item >= MEMINFO_logical_end)
|
2016-05-11 22:30:00 +05:30
|
|
|
break;
|
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-10 10:30:00 +05:30
|
|
|
Item_table[item].setsfunc(this, hist);
|
2016-05-11 22:30:00 +05:30
|
|
|
++this;
|
|
|
|
|
}
|
|
|
|
|
return;
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_assign_results
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
static void meminfo_extents_free_all (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info)
|
2016-05-11 22:30:00 +05:30
|
|
|
{
|
2016-07-01 10:30:00 +05:30
|
|
|
while (info->extents) {
|
2016-05-11 22:30:00 +05:30
|
|
|
struct stacks_extent *p = info->extents;
|
|
|
|
|
info->extents = info->extents->next;
|
|
|
|
|
free(p);
|
2016-07-01 10:30:00 +05:30
|
|
|
};
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_extents_free_all
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
static inline struct meminfo_result *meminfo_itemize_stack (
|
2016-05-11 22:30:00 +05:30
|
|
|
struct meminfo_result *p,
|
|
|
|
|
int depth,
|
|
|
|
|
enum meminfo_item *items)
|
|
|
|
|
{
|
|
|
|
|
struct meminfo_result *p_sav = p;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < depth; i++) {
|
|
|
|
|
p->item = items[i];
|
|
|
|
|
++p;
|
|
|
|
|
}
|
|
|
|
|
return p_sav;
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_itemize_stack
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
static inline int meminfo_items_check_failed (
|
2016-05-11 22:30:00 +05:30
|
|
|
int numitems,
|
|
|
|
|
enum meminfo_item *items)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* if an enum is passed instead of an address of one or more enums, ol' gcc
|
|
|
|
|
* will silently convert it to an address (possibly NULL). only clang will
|
|
|
|
|
* offer any sort of warning like the following:
|
|
|
|
|
*
|
|
|
|
|
* warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'enum meminfo_item *'
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
* my_stack = procps_meminfo_select(info, MEMINFO_noop, num);
|
2016-06-01 10:30:00 +05:30
|
|
|
* ^~~~~~~~~~~~~~~~
|
2016-05-11 22:30:00 +05:30
|
|
|
*/
|
|
|
|
|
if (numitems < 1
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
|| (void *)items < (void *)(unsigned long)(2 * MEMINFO_logical_end))
|
2017-11-18 10:30:00 +05:30
|
|
|
return 1;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
for (i = 0; i < numitems; i++) {
|
|
|
|
|
// a meminfo_item is currently unsigned, but we'll protect our future
|
|
|
|
|
if (items[i] < 0)
|
2017-11-18 10:30:00 +05:30
|
|
|
return 1;
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
if (items[i] >= MEMINFO_logical_end)
|
2017-11-18 10:30:00 +05:30
|
|
|
return 1;
|
2016-05-11 22:30:00 +05:30
|
|
|
}
|
2015-06-20 18:38:47 +05:30
|
|
|
|
|
|
|
|
return 0;
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_items_check_failed
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
static int meminfo_make_hash_failed (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info)
|
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-10 10:30:00 +05:30
|
|
|
{
|
2021-02-23 11:30:00 +05:30
|
|
|
#define htVAL(f) e.key = STRINGIFY(f); e.data = &info->hist.new. f; \
|
2017-11-18 10:30:00 +05:30
|
|
|
if (!hsearch_r(e, ENTER, &ep, &info->hashtab)) return 1;
|
2021-02-23 11:30:00 +05:30
|
|
|
#define htXTRA(k,f) e.key = STRINGIFY(k); e.data = &info->hist.new. f; \
|
2017-11-18 10:30:00 +05:30
|
|
|
if (!hsearch_r(e, ENTER, &ep, &info->hashtab)) return 1;
|
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-10 10:30:00 +05:30
|
|
|
ENTRY e, *ep;
|
|
|
|
|
size_t n;
|
|
|
|
|
|
2017-09-21 10:30:00 +05:30
|
|
|
// will also include those derived fields (more is better)
|
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-10 10:30:00 +05:30
|
|
|
n = sizeof(struct meminfo_data) / sizeof(unsigned long);
|
|
|
|
|
// we'll follow the hsearch recommendation of an extra 25%
|
2017-11-18 10:30:00 +05:30
|
|
|
if (!hcreate_r(n + (n / 4), &info->hashtab))
|
|
|
|
|
return 1;
|
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-10 10:30:00 +05:30
|
|
|
|
|
|
|
|
htVAL(Active)
|
|
|
|
|
htXTRA(Active(anon), Active_anon)
|
|
|
|
|
htXTRA(Active(file), Active_file)
|
|
|
|
|
htVAL(AnonHugePages)
|
|
|
|
|
htVAL(AnonPages)
|
|
|
|
|
htVAL(Bounce)
|
|
|
|
|
htVAL(Buffers)
|
|
|
|
|
htVAL(Cached)
|
|
|
|
|
htVAL(CmaFree)
|
|
|
|
|
htVAL(CmaTotal)
|
|
|
|
|
htVAL(CommitLimit)
|
|
|
|
|
htVAL(Committed_AS)
|
|
|
|
|
htVAL(DirectMap1G)
|
|
|
|
|
htVAL(DirectMap2M)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
htVAL(DirectMap4M)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(DirectMap4k)
|
|
|
|
|
htVAL(Dirty)
|
2020-08-07 10:30:00 +05:30
|
|
|
htVAL(FileHugePages)
|
|
|
|
|
htVAL(FilePmdMapped)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(HardwareCorrupted)
|
|
|
|
|
htVAL(HighFree)
|
|
|
|
|
htVAL(HighTotal)
|
|
|
|
|
htVAL(HugePages_Free)
|
|
|
|
|
htVAL(HugePages_Rsvd)
|
|
|
|
|
htVAL(HugePages_Surp)
|
|
|
|
|
htVAL(HugePages_Total)
|
|
|
|
|
htVAL(Hugepagesize)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
htVAL(Hugetlb)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(Inactive)
|
|
|
|
|
htXTRA(Inactive(anon), Inactive_anon)
|
|
|
|
|
htXTRA(Inactive(file), Inactive_file)
|
2018-12-01 11:30:00 +05:30
|
|
|
htVAL(KReclaimable)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(KernelStack)
|
|
|
|
|
htVAL(LowFree)
|
|
|
|
|
htVAL(LowTotal)
|
|
|
|
|
htVAL(Mapped)
|
|
|
|
|
htVAL(MemAvailable)
|
|
|
|
|
htVAL(MemFree)
|
|
|
|
|
htVAL(MemTotal)
|
|
|
|
|
htVAL(Mlocked)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
htVAL(MmapCopy)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(NFS_Unstable)
|
|
|
|
|
htVAL(PageTables)
|
library: refactored some header file items and origins
This commit is intended as a refinement of the patches
mentioned below, where origins/sources of newlib items
were added to the header files for user documentation.
However, if those additions are to be truly effective,
along with kernel documentation (where available), the
following prerequisites must also have been satisfied:
. our identifiers closely align with linux field names
. our derived items are documented or self-documenting
Satisfying those prerequisites prompted this patch and
for these changes, kernel sources were emphasized over
available documentation (shame on me, it should always
have been so). And, while some 'new' fields were found
to be conditional, they were included unconditionally.
These changes appear more extensive than they actually
need be since I have attempted to enforce some spacing
conventions. So, I've summarize the significant things
in the sections that follow. For a proper perspective,
use: 'git diff --ignore-space-change' (good as alias).
___________________________________________ <PIDS> api
This api is unique in that there exists many different
file/directory origins subordinate to /proc/<pid>. And
our item identifiers are sometimes coerced so as to be
able to group related or similar enumerators together.
So, users needed more help relating our identifiers to
an actual documented field. Thus, we will now also add
the field names as with 'stat: delayacct_blkio_ticks'.
Each item ending with a '_C' now consistently includes
both the parent's count/time plus waited for children.
That 'RTPRIO' guy was renamed/relocated as PRIORITY_RT
since its original name is an implementation artifact.
___________________________________________ <STAT> api
The only api change was to correct a typo ('dervied').
_________________________________________ <VMSTAT> api
Even ignoring white space, this interface received the
largest number of changes. Mostly, this was because of
deficiencies in the proc(5) documentation. Recall that
this documentation already sorely lacks any substance.
Usually, just kernel releases are noted, not contents.
When compared to kernel source, that proc(5) contained
many non-existent fields and also omitted many others.
________________________________________ <MEMINFO> api
Sadly, with this api many of the changes were simply a
correction of some earlier 'human error' where several
fields where hashed then tracked but never represented
with an item enumerator in this meminfo.h header file.
_______________________________________ <SLABINFO> api
The 'SLABS' (summary) & 'SLABNODE' items were reversed
since the former are derived from the separate caches.
More significantly, those 'SLABNODE' guys were renamed
to 'SLAB' since they concern individual caches and the
concept of 'nodes' is really an implementation detail.
Also, several enumerators were changed to more closely
agree with official slabinfo(5) documentation referred
to in what we're treating as a base document: proc(5).
Lastly, while those 'SLABS' items are solely a product
of our library and not represented in slabinfo(5), the
names attempt to parallel those found as 'SLAB' items.
______________________________________ <DISKSTATS> api
One enumeration identifier was changed so as to better
reflect its relationship to that actual documentation:
'Documentation/iostats.txt', as referenced in proc(5).
Reference(s):
. 12/2018, item origins added (and commit msg history)
commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14
. 01/2019, <stat> origins tweaked
commit 201e816b26ddaccc923ec40977c92037cdd0c34e
Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-03-12 11:30:00 +05:30
|
|
|
htVAL(Percpu)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(SReclaimable)
|
|
|
|
|
htVAL(SUnreclaim)
|
2020-08-07 10:30:00 +05:30
|
|
|
htVAL(ShadowCallStack)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(Shmem)
|
2016-08-11 21:41:11 +05:30
|
|
|
htVAL(ShmemHugePages)
|
|
|
|
|
htVAL(ShmemPmdMapped)
|
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-10 10:30:00 +05:30
|
|
|
htVAL(Slab)
|
|
|
|
|
htVAL(SwapCached)
|
|
|
|
|
htVAL(SwapFree)
|
|
|
|
|
htVAL(SwapTotal)
|
|
|
|
|
htVAL(Unevictable)
|
|
|
|
|
htVAL(VmallocChunk)
|
|
|
|
|
htVAL(VmallocTotal)
|
|
|
|
|
htVAL(VmallocUsed)
|
|
|
|
|
htVAL(Writeback)
|
|
|
|
|
htVAL(WritebackTmp)
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
#undef htVAL
|
|
|
|
|
#undef htXTRA
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_make_hash_failed
|
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-10 10:30:00 +05:30
|
|
|
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
/*
|
2016-08-21 10:30:00 +05:30
|
|
|
* meminfo_read_failed():
|
2015-06-20 18:38:47 +05:30
|
|
|
*
|
|
|
|
|
* Read the data out of /proc/meminfo putting the information
|
|
|
|
|
* into the supplied info structure
|
|
|
|
|
*/
|
2016-08-21 10:30:00 +05:30
|
|
|
static int meminfo_read_failed (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
2016-05-11 22:30:00 +05:30
|
|
|
/* a 'memory history reference' macro for readability,
|
|
|
|
|
so we can focus the field names ... */
|
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-10 10:30:00 +05:30
|
|
|
#define mHr(f) info->hist.new. f
|
2020-06-29 10:30:00 +05:30
|
|
|
char buf[MEMINFO_BUFF];
|
2015-06-20 18:38:47 +05:30
|
|
|
char *head, *tail;
|
|
|
|
|
int size;
|
|
|
|
|
unsigned long *valptr;
|
2015-06-28 10:30:00 +05:30
|
|
|
signed long mem_used;
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
// remember history from last time around
|
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-10 10:30:00 +05:30
|
|
|
memcpy(&info->hist.old, &info->hist.new, sizeof(struct meminfo_data));
|
2016-05-11 22:30:00 +05:30
|
|
|
// clear out the soon to be 'current' values
|
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-10 10:30:00 +05:30
|
|
|
memset(&info->hist.new, 0, sizeof(struct meminfo_data));
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (-1 == info->meminfo_fd
|
2021-02-22 11:30:00 +05:30
|
|
|
&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY))))
|
2017-11-18 10:30:00 +05:30
|
|
|
return 1;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
|
2017-11-18 10:30:00 +05:30
|
|
|
return 1;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
for (;;) {
|
|
|
|
|
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
|
|
|
|
|
if (errno == EINTR || errno == EAGAIN)
|
|
|
|
|
continue;
|
2017-11-18 10:30:00 +05:30
|
|
|
return 1;
|
2015-06-28 10:30:00 +05:30
|
|
|
}
|
|
|
|
|
break;
|
2015-06-20 18:38:47 +05:30
|
|
|
}
|
2017-11-18 10:30:00 +05:30
|
|
|
if (size == 0) {
|
|
|
|
|
errno = EIO;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
2015-06-20 18:38:47 +05:30
|
|
|
buf[size] = '\0';
|
|
|
|
|
|
|
|
|
|
head = buf;
|
2016-07-13 10:30:00 +05:30
|
|
|
|
2016-07-03 10:30:00 +05:30
|
|
|
for (;;) {
|
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-10 10:30:00 +05:30
|
|
|
static ENTRY e; // just to keep coverity off our backs (e.data)
|
|
|
|
|
ENTRY *ep;
|
|
|
|
|
|
2021-02-23 11:30:00 +05:30
|
|
|
if (!(tail = strchr(head, ':')))
|
2015-06-28 10:30:00 +05:30
|
|
|
break;
|
|
|
|
|
*tail = '\0';
|
|
|
|
|
valptr = NULL;
|
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-10 10:30:00 +05:30
|
|
|
|
|
|
|
|
e.key = head;
|
|
|
|
|
if (hsearch_r(e, FIND, &ep, &info->hashtab))
|
|
|
|
|
valptr = ep->data;
|
2021-02-22 11:30:00 +05:30
|
|
|
head = tail + 1;
|
2016-07-03 10:30:00 +05:30
|
|
|
if (valptr)
|
2021-02-22 11:30:00 +05:30
|
|
|
*valptr = strtoul(head, NULL, 10);
|
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-10 10:30:00 +05:30
|
|
|
|
2021-02-22 11:30:00 +05:30
|
|
|
if (!(tail = strchr(head, '\n')))
|
2015-06-28 10:30:00 +05:30
|
|
|
break;
|
|
|
|
|
head = tail + 1;
|
2016-07-03 10:30:00 +05:30
|
|
|
}
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (0 == mHr(MemAvailable))
|
|
|
|
|
mHr(MemAvailable) = mHr(MemFree);
|
2017-05-29 11:41:11 +05:30
|
|
|
mHr(derived_mem_cached) = mHr(Cached) + mHr(SReclaimable);
|
|
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
/* if 'available' is greater than 'total' or our calculation of mem_used
|
|
|
|
|
overflows, that's symptomatic of running within a lxc container where
|
|
|
|
|
such values will be dramatically distorted over those of the host. */
|
2016-05-11 22:30:00 +05:30
|
|
|
if (mHr(MemAvailable) > mHr(MemTotal))
|
|
|
|
|
mHr(MemAvailable) = mHr(MemFree);
|
2017-05-29 11:41:11 +05:30
|
|
|
mem_used = mHr(MemTotal) - mHr(MemFree) - mHr(derived_mem_cached) - mHr(Buffers);
|
2015-06-28 10:30:00 +05:30
|
|
|
if (mem_used < 0)
|
2016-05-11 22:30:00 +05:30
|
|
|
mem_used = mHr(MemTotal) - mHr(MemFree);
|
|
|
|
|
mHr(derived_mem_used) = (unsigned long)mem_used;
|
|
|
|
|
|
|
|
|
|
if (mHr(HighFree) < mHr(HighTotal))
|
|
|
|
|
mHr(derived_mem_hi_used) = mHr(HighTotal) - mHr(HighFree);
|
|
|
|
|
|
|
|
|
|
if (0 == mHr(LowTotal)) {
|
|
|
|
|
mHr(LowTotal) = mHr(MemTotal);
|
|
|
|
|
mHr(LowFree) = mHr(MemFree);
|
|
|
|
|
}
|
|
|
|
|
if (mHr(LowFree) < mHr(LowTotal))
|
|
|
|
|
mHr(derived_mem_lo_used) = mHr(LowTotal) - mHr(LowFree);
|
|
|
|
|
|
|
|
|
|
if (mHr(SwapFree) < mHr(SwapTotal))
|
|
|
|
|
mHr(derived_swap_used) = mHr(SwapTotal) - mHr(SwapFree);
|
2017-09-07 10:30:00 +05:30
|
|
|
else
|
|
|
|
|
mHr(derived_swap_used) = 0;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
return 0;
|
2016-05-11 22:30:00 +05:30
|
|
|
#undef mHr
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_read_failed
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2016-08-21 10:30:00 +05:30
|
|
|
* meminfo_stacks_alloc():
|
2016-05-11 22:30:00 +05:30
|
|
|
*
|
|
|
|
|
* Allocate and initialize one or more stacks each of which is anchored in an
|
2016-08-21 10:30:00 +05:30
|
|
|
* associated context structure.
|
2016-05-11 22:30:00 +05:30
|
|
|
*
|
|
|
|
|
* All such stacks will have their result structures properly primed with
|
|
|
|
|
* 'items', while the result itself will be zeroed.
|
|
|
|
|
*
|
|
|
|
|
* Returns a stacks_extent struct anchoring the 'heads' of each new stack.
|
|
|
|
|
*/
|
2016-08-21 10:30:00 +05:30
|
|
|
static struct stacks_extent *meminfo_stacks_alloc (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info,
|
2016-05-11 22:30:00 +05:30
|
|
|
int maxstacks)
|
|
|
|
|
{
|
|
|
|
|
struct stacks_extent *p_blob;
|
|
|
|
|
struct meminfo_stack **p_vect;
|
|
|
|
|
struct meminfo_stack *p_head;
|
|
|
|
|
size_t vect_size, head_size, list_size, blob_size;
|
|
|
|
|
void *v_head, *v_list;
|
|
|
|
|
int i;
|
|
|
|
|
|
2017-09-21 10:30:00 +05:30
|
|
|
vect_size = sizeof(void *) * maxstacks; // size of the addr vectors |
|
|
|
|
|
vect_size += sizeof(void *); // plus NULL addr delimiter |
|
|
|
|
|
head_size = sizeof(struct meminfo_stack); // size of that head struct |
|
|
|
|
|
list_size = sizeof(struct meminfo_result)*info->numitems; // any single results stack |
|
|
|
|
|
blob_size = sizeof(struct stacks_extent); // the extent anchor itself |
|
|
|
|
|
blob_size += vect_size; // plus room for addr vects |
|
|
|
|
|
blob_size += head_size * maxstacks; // plus room for head thing |
|
|
|
|
|
blob_size += list_size * maxstacks; // plus room for our stacks |
|
|
|
|
|
|
|
|
|
|
/* note: all of this memory is allocated in a single blob, facilitating a later free(). |
|
|
|
|
|
as a minimum, it is important that the result structures themselves always are |
|
|
|
|
|
contiguous within each stack since they're accessed through relative position. | */
|
2016-05-11 22:30:00 +05:30
|
|
|
if (NULL == (p_blob = calloc(1, blob_size)))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2017-09-21 10:30:00 +05:30
|
|
|
p_blob->next = info->extents; // push this extent onto... |
|
|
|
|
|
info->extents = p_blob; // ...some existing extents |
|
|
|
|
|
p_vect = (void *)p_blob + sizeof(struct stacks_extent); // prime our vector pointer |
|
|
|
|
|
p_blob->stacks = p_vect; // set actual vectors start |
|
|
|
|
|
v_head = (void *)p_vect + vect_size; // prime head pointer start |
|
|
|
|
|
v_list = v_head + (head_size * maxstacks); // prime our stacks pointer |
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
for (i = 0; i < maxstacks; i++) {
|
|
|
|
|
p_head = (struct meminfo_stack *)v_head;
|
2016-08-21 10:30:00 +05:30
|
|
|
p_head->head = meminfo_itemize_stack((struct meminfo_result *)v_list, info->numitems, info->items);
|
2016-05-11 22:30:00 +05:30
|
|
|
p_blob->stacks[i] = p_head;
|
|
|
|
|
v_list += list_size;
|
|
|
|
|
v_head += head_size;
|
|
|
|
|
}
|
|
|
|
|
p_blob->ext_numstacks = maxstacks;
|
|
|
|
|
return p_blob;
|
2016-08-21 10:30:00 +05:30
|
|
|
} // end: meminfo_stacks_alloc
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
// --- standard required functions --------------------------------------------
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/*
|
|
|
|
|
* procps_meminfo_new:
|
|
|
|
|
*
|
|
|
|
|
* Create a new container to hold the stat information
|
|
|
|
|
*
|
|
|
|
|
* The initial refcount is 1, and needs to be decremented
|
|
|
|
|
* to release the resources of the structure.
|
|
|
|
|
*
|
2016-07-13 10:30:00 +05:30
|
|
|
* Returns: < 0 on failure, 0 on success along with
|
|
|
|
|
* a pointer to a new context struct
|
2016-05-11 22:30:00 +05:30
|
|
|
*/
|
|
|
|
|
PROCPS_EXPORT int procps_meminfo_new (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info **info)
|
2016-05-11 22:30:00 +05:30
|
|
|
{
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *p;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2020-08-10 10:30:00 +05:30
|
|
|
#ifdef ITEMTABLE_DEBUG
|
|
|
|
|
int i, failed = 0;
|
|
|
|
|
for (i = 0; i < MAXTABLE(Item_table); i++) {
|
|
|
|
|
if (i != Item_table[i].enumnumb) {
|
|
|
|
|
fprintf(stderr, "%s: enum/table error: Item_table[%d] was %s, but its value is %d\n"
|
|
|
|
|
, __FILE__, i, Item_table[i].enum2str, Item_table[i].enumnumb);
|
|
|
|
|
failed = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (failed) _Exit(EXIT_FAILURE);
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (info == NULL || *info != NULL)
|
|
|
|
|
return -EINVAL;
|
2016-07-21 10:30:00 +05:30
|
|
|
if (!(p = calloc(1, sizeof(struct meminfo_info))))
|
2016-05-11 22:30:00 +05:30
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
p->refcount = 1;
|
|
|
|
|
p->meminfo_fd = -1;
|
|
|
|
|
|
2017-11-18 10:30:00 +05:30
|
|
|
if (meminfo_make_hash_failed(p)) {
|
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-10 10:30:00 +05:30
|
|
|
free(p);
|
2017-11-18 10:30:00 +05:30
|
|
|
return -errno;
|
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-10 10:30:00 +05:30
|
|
|
}
|
|
|
|
|
|
2016-09-17 15:14:44 +05:30
|
|
|
/* do a priming read here for the following potential benefits: |
|
|
|
|
|
1) ensure there will be no problems with subsequent access |
|
2016-12-31 11:30:00 +05:30
|
|
|
2) make delta results potentially useful, even if 1st time |
|
|
|
|
|
3) elimnate need for history distortions 1st time 'switch' | */
|
2017-11-18 10:30:00 +05:30
|
|
|
if (meminfo_read_failed(p)) {
|
2016-09-17 15:14:44 +05:30
|
|
|
procps_meminfo_unref(&p);
|
2017-11-18 10:30:00 +05:30
|
|
|
return -errno;
|
2016-09-17 15:14:44 +05:30
|
|
|
}
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
*info = p;
|
|
|
|
|
return 0;
|
|
|
|
|
} // end: procps_meminfo_new
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
PROCPS_EXPORT int procps_meminfo_ref (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
|
|
|
|
if (info == NULL)
|
2015-06-30 10:30:00 +05:30
|
|
|
return -EINVAL;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
info->refcount++;
|
2015-06-30 10:30:00 +05:30
|
|
|
return info->refcount;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: procps_meminfo_ref
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
PROCPS_EXPORT int procps_meminfo_unref (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info **info)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
2015-06-30 10:30:00 +05:30
|
|
|
if (info == NULL || *info == NULL)
|
|
|
|
|
return -EINVAL;
|
2016-11-22 20:40:10 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
(*info)->refcount--;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2016-11-22 20:40:10 +05:30
|
|
|
if ((*info)->refcount < 1) {
|
2017-11-18 10:30:00 +05:30
|
|
|
int errno_sav = errno;
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if ((*info)->extents)
|
2016-08-21 10:30:00 +05:30
|
|
|
meminfo_extents_free_all((*info));
|
2016-05-11 22:30:00 +05:30
|
|
|
if ((*info)->items)
|
|
|
|
|
free((*info)->items);
|
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-10 10:30:00 +05:30
|
|
|
hdestroy_r(&(*info)->hashtab);
|
2016-11-22 20:40:10 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
free(*info);
|
|
|
|
|
*info = NULL;
|
2017-11-18 10:30:00 +05:30
|
|
|
|
|
|
|
|
errno = errno_sav;
|
2015-06-30 10:30:00 +05:30
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
return (*info)->refcount;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: procps_meminfo_unref
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
// --- variable interface functions -------------------------------------------
|
|
|
|
|
|
2016-06-18 10:30:00 +05:30
|
|
|
PROCPS_EXPORT struct meminfo_result *procps_meminfo_get (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info,
|
2016-05-11 22:30:00 +05:30
|
|
|
enum meminfo_item item)
|
2015-07-11 10:30:00 +05:30
|
|
|
{
|
2016-05-11 22:30:00 +05:30
|
|
|
static time_t sav_secs;
|
|
|
|
|
time_t cur_secs;
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2017-11-18 10:30:00 +05:30
|
|
|
errno = EINVAL;
|
2016-06-01 10:30:00 +05:30
|
|
|
if (info == NULL)
|
2016-06-18 10:30:00 +05:30
|
|
|
return NULL;
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
if (item < 0 || item >= MEMINFO_logical_end)
|
2016-06-18 10:30:00 +05:30
|
|
|
return NULL;
|
2017-11-18 10:30:00 +05:30
|
|
|
errno = 0;
|
2016-06-01 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* we will NOT read the meminfo file with every call - rather, we'll offer
|
|
|
|
|
a granularity of 1 second between reads ... */
|
|
|
|
|
cur_secs = time(NULL);
|
|
|
|
|
if (1 <= cur_secs - sav_secs) {
|
2016-08-21 10:30:00 +05:30
|
|
|
if (meminfo_read_failed(info))
|
2016-06-18 10:30:00 +05:30
|
|
|
return NULL;
|
2016-05-11 22:30:00 +05:30
|
|
|
sav_secs = cur_secs;
|
2015-07-11 10:30:00 +05:30
|
|
|
}
|
|
|
|
|
|
2016-06-18 10:30:00 +05:30
|
|
|
info->get_this.item = item;
|
2017-11-18 10:30:00 +05:30
|
|
|
// with 'get', we must NOT honor the usual 'noop' guarantee
|
|
|
|
|
info->get_this.result.ul_int = 0;
|
2016-06-18 10:30:00 +05:30
|
|
|
Item_table[item].setsfunc(&info->get_this, &info->hist);
|
|
|
|
|
|
|
|
|
|
return &info->get_this;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: procps_meminfo_get
|
2015-07-21 10:30:00 +05:30
|
|
|
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* procps_meminfo_select():
|
2015-07-11 10:30:00 +05:30
|
|
|
*
|
2016-05-11 22:30:00 +05:30
|
|
|
* Harvest all the requested MEM and/or SWAP information then return
|
|
|
|
|
* it in a results stack.
|
|
|
|
|
*
|
|
|
|
|
* Returns: pointer to a meminfo_stack struct on success, NULL on error.
|
2015-07-11 10:30:00 +05:30
|
|
|
*/
|
2016-05-11 22:30:00 +05:30
|
|
|
PROCPS_EXPORT struct meminfo_stack *procps_meminfo_select (
|
2016-07-21 10:30:00 +05:30
|
|
|
struct meminfo_info *info,
|
2016-05-11 22:30:00 +05:30
|
|
|
enum meminfo_item *items,
|
|
|
|
|
int numitems)
|
2015-07-11 10:30:00 +05:30
|
|
|
{
|
2017-11-18 10:30:00 +05:30
|
|
|
errno = EINVAL;
|
2015-07-11 10:30:00 +05:30
|
|
|
if (info == NULL || items == NULL)
|
|
|
|
|
return NULL;
|
2016-08-21 10:30:00 +05:30
|
|
|
if (meminfo_items_check_failed(numitems, items))
|
2015-07-11 10:30:00 +05:30
|
|
|
return NULL;
|
2017-11-18 10:30:00 +05:30
|
|
|
errno = 0;
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* is this the first time or have things changed since we were last called?
|
|
|
|
|
if so, gotta' redo all of our stacks stuff ... */
|
|
|
|
|
if (info->numitems != numitems + 1
|
|
|
|
|
|| memcmp(info->items, items, sizeof(enum meminfo_item) * numitems)) {
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
// allow for our MEMINFO_logical_end
|
2016-05-11 22:30:00 +05:30
|
|
|
if (!(info->items = realloc(info->items, sizeof(enum meminfo_item) * (numitems + 1))))
|
2016-05-12 03:22:36 +05:30
|
|
|
return NULL;
|
2016-05-11 22:30:00 +05:30
|
|
|
memcpy(info->items, items, sizeof(enum meminfo_item) * numitems);
|
library: removed all the 'PROCPS_' enumerator prefixes
Many of our item enumerator identifiers are very long,
especially in that <VMSTAT> module. Additionally, they
all contain the exact same universal 'PROCPS_' prefix.
The origins for this are likely found in the desire to
avoid name clashes with other potential include files.
But with procps-ng newlib, we've probably gone way too
far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more
protection against clash than 'PIDS_TICS_SYSTEM' does?
I don't think so. Besides, no matter how big that name
becomes, one can never guarantee they'll never be some
clash. And, conversely, extremely short names will not
always create conflict. Of course, in either case when
some clash occurs, one can always #undef that problem.
Thus, this commit will eliminate that 'PROCPS_' prefix
making all of those enum identifiers a little shorter.
And, we'll still be well above some ridiculously short
(criminally short) names found in some common headers:
- - - - - - - - - - <term.h>
- 'tab', 'TTY', etc
- - - - - - - - - - - - - - - - <search.h>
- 'ENTER', ENTRY', 'FIND', etc
------------------------------------------------------
Finally, with this as a last of the wholesale changes,
we will have established the naming conventions below:
. only functions will begin with that 'procps_' prefix
. exposed structures begin with the module/header name
. item enumerators begin like structs, but capitalized
. other enumerators work exactly like item enumerators
. macros and constants begin just like the enumerators
------------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|
|
|
info->items[numitems] = MEMINFO_logical_end;
|
2016-05-11 22:30:00 +05:30
|
|
|
info->numitems = numitems + 1;
|
|
|
|
|
if (info->extents)
|
2016-08-21 10:30:00 +05:30
|
|
|
meminfo_extents_free_all(info);
|
2015-07-11 10:30:00 +05:30
|
|
|
}
|
2016-05-11 22:30:00 +05:30
|
|
|
if (!info->extents
|
2016-11-24 23:42:12 +05:30
|
|
|
&& (!meminfo_stacks_alloc(info, 1)))
|
2016-05-11 22:30:00 +05:30
|
|
|
return NULL;
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-08-21 10:30:00 +05:30
|
|
|
if (meminfo_read_failed(info))
|
2015-07-11 10:30:00 +05:30
|
|
|
return NULL;
|
2016-08-21 10:30:00 +05:30
|
|
|
meminfo_assign_results(info->extents->stacks[0], &info->hist);
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
return info->extents->stacks[0];
|
|
|
|
|
} // end: procps_meminfo_select
|
2016-08-05 10:30:00 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
// --- special debugging function(s) ------------------------------------------
|
|
|
|
|
/*
|
|
|
|
|
* The following isn't part of the normal programming interface. Rather,
|
|
|
|
|
* it exists to validate result types referenced in application programs.
|
|
|
|
|
*
|
|
|
|
|
* It's used only when:
|
|
|
|
|
* 1) the 'XTRA_PROCPS_DEBUG' has been defined, or
|
2020-07-13 10:30:00 +05:30
|
|
|
* 2) an #include of 'xtra-procps-debug.h' is used
|
2016-08-05 10:30:00 +05:30
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
PROCPS_EXPORT struct meminfo_result *xtra_meminfo_get (
|
|
|
|
|
struct meminfo_info *info,
|
|
|
|
|
enum meminfo_item actual_enum,
|
|
|
|
|
const char *typestr,
|
|
|
|
|
const char *file,
|
|
|
|
|
int lineno)
|
|
|
|
|
{
|
|
|
|
|
struct meminfo_result *r = procps_meminfo_get(info, actual_enum);
|
|
|
|
|
|
2016-08-06 21:41:11 +05:30
|
|
|
if (actual_enum < 0 || actual_enum >= MEMINFO_logical_end) {
|
|
|
|
|
fprintf(stderr, "%s line %d: invalid item = %d, type = %s\n"
|
|
|
|
|
, file, lineno, actual_enum, typestr);
|
|
|
|
|
}
|
2016-08-05 10:30:00 +05:30
|
|
|
if (r) {
|
|
|
|
|
char *str = Item_table[r->item].type2str;
|
|
|
|
|
if (str[0]
|
|
|
|
|
&& (strcmp(typestr, str)))
|
|
|
|
|
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
|
|
|
|
|
}
|
|
|
|
|
return r;
|
|
|
|
|
} // end: xtra_meminfo_get_
|
|
|
|
|
|
|
|
|
|
|
2016-08-08 11:53:45 +05:30
|
|
|
PROCPS_EXPORT struct meminfo_result *xtra_meminfo_val (
|
2016-08-05 10:30:00 +05:30
|
|
|
int relative_enum,
|
|
|
|
|
const char *typestr,
|
|
|
|
|
const struct meminfo_stack *stack,
|
|
|
|
|
struct meminfo_info *info,
|
|
|
|
|
const char *file,
|
|
|
|
|
int lineno)
|
|
|
|
|
{
|
|
|
|
|
char *str;
|
2016-08-08 11:53:45 +05:30
|
|
|
int i;
|
2016-08-05 10:30:00 +05:30
|
|
|
|
2016-08-08 11:53:45 +05:30
|
|
|
for (i = 0; stack->head[i].item < MEMINFO_logical_end; i++)
|
|
|
|
|
;
|
|
|
|
|
if (relative_enum < 0 || relative_enum >= i) {
|
2020-07-13 10:30:00 +05:30
|
|
|
fprintf(stderr, "%s line %d: invalid relative_enum = %d, valid range = 0-%d\n"
|
|
|
|
|
, file, lineno, relative_enum, i-1);
|
2016-08-08 11:53:45 +05:30
|
|
|
return NULL;
|
2016-08-05 10:30:00 +05:30
|
|
|
}
|
2016-08-08 11:53:45 +05:30
|
|
|
str = Item_table[stack->head[relative_enum].item].type2str;
|
2016-08-05 10:30:00 +05:30
|
|
|
if (str[0]
|
2016-08-08 11:53:45 +05:30
|
|
|
&& (strcmp(typestr, str))) {
|
2016-08-05 10:30:00 +05:30
|
|
|
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
|
2016-08-08 11:53:45 +05:30
|
|
|
}
|
|
|
|
|
return &stack->head[relative_enum];
|
2018-06-03 10:30:00 +05:30
|
|
|
(void)info;
|
2016-08-05 10:30:00 +05:30
|
|
|
} // end: xtra_meminfo_val
|
