2011-12-23 03:48:43 +05:30
|
|
|
LIBPROCPS_0 {
|
2003-01-24 15:45:23 +05:30
|
|
|
global:
|
2015-09-11 10:30:00 +05:30
|
|
|
fatal_proc_unmounted;
|
2015-06-29 18:01:36 +05:30
|
|
|
procps_cpu_count;
|
library: normalize/standardize an i/f, <DISKSTATS> api
This patch will bring this interface up to our 3rd gen
standards. The following summarizes the major changes.
* New delta provisions have been added to most fields.
There are, of course, some fields for which a delta is
inappropriate. They include the identifying items such
as name, type, major and minor. Plus the io_inprogress
field which already acts, in effect, as a delta value.
* To provide delta support, dev_node historical values
have become persistent. By the same token, the library
must provide for future removal of disks/partitions. A
timestamp is used to detect 'stale' data which will be
deleted so as not to satisfy some get, select or reap.
* Such persistent support is provided by a linked list
which, by default, grows from the bottom down so as to
maintain compatibility with the /proc/diskstats order.
Initially, I was tempted to use the GNU tsearch (tree)
provisions until I discovered the overhead of building
that tree plus costs of a subsequent 'twalk'. Besides,
walking such a tree means retrieval order would differ
from an order required/expected by the vmstat program.
* The '/sys/block' directory is no longer scanned with
every refresh cycle. Rather, it's only accessed when a
node is first encountered. Then, that node's 'type' is
persistent for its lifetime like several other fields.
* A sort provision was included, at virtually no cost,
even though such a provision was not currently needed.
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-20 10:30:00 +05:30
|
|
|
procps_diskstats_new;
|
|
|
|
|
procps_diskstats_ref;
|
|
|
|
|
procps_diskstats_unref;
|
|
|
|
|
procps_diskstats_get;
|
|
|
|
|
procps_diskstats_reap;
|
|
|
|
|
procps_diskstats_select;
|
|
|
|
|
procps_diskstats_sort;
|
2015-06-24 17:46:16 +05:30
|
|
|
procps_hertz_get;
|
2015-06-19 16:30:46 +05:30
|
|
|
procps_linux_version;
|
2015-07-01 17:17:30 +05:30
|
|
|
procps_loadavg;
|
2015-06-20 18:38:47 +05:30
|
|
|
procps_meminfo_new;
|
|
|
|
|
procps_meminfo_ref;
|
|
|
|
|
procps_meminfo_unref;
|
|
|
|
|
procps_meminfo_get;
|
2016-05-11 22:30:00 +05:30
|
|
|
procps_meminfo_select;
|
2015-09-03 18:02:19 +05:30
|
|
|
procps_ns_get_name;
|
|
|
|
|
procps_ns_get_id;
|
|
|
|
|
procps_ns_read_pid;
|
2016-04-16 12:33:57 +05:30
|
|
|
procps_pid_length;
|
2015-08-19 10:30:00 +05:30
|
|
|
procps_pids_new;
|
|
|
|
|
procps_pids_ref;
|
library: standardize portions of interface, <PIDS> api
This represents a rather major interface redesign. The
following highlights most of the changes/enhancements.
. The 'read' interface (employed by pgrep & pidof) saw
the biggest change. The 'open', 'next' and 'shut' guys
all went bye-bye, replaced by a single 'get' function.
. The items specified at 'new' time no longer serve as
the maximum. In fact, items & numitems are now treated
as optional, should callers prefer to wait until later
when the 'reset' function would then become mandatory.
. Even at 'reset' time, the stacks are not tied to any
sort of maximum. They will grow dynamically as needed.
. The order of some parameters was changed to parallel
that found in our other APIs. Specifically, when items
& numitems are needed they're specified in that order.
. A user will no longer be prevented from concurrently
employing any accessor functions. In other words, that
'get' (old 'read') won't preclude 'reap' and 'select'.
. A duplicate enumerator was found dealing with locked
resident pages. So, the name VM_LOCK was eliminated in
favor of VM_RSS_LOCKED, which is way more descriptive.
. The struct address returned to callers following any
reap() or select() is now more sharable as pids_fetch.
. Some input parameter names were changed to make them
more descriptive of the intended purpose/requirements.
------------------------------------------------------
Internally, there were numerous implementation changes
made that did not directly impact any potential users.
. That #define FPRINT_STACKS was eliminated along with
the associated supporting function and its invocation.
. Addresses returned following 'reap' or 'select' will
now be NULL delimited, so one has the option of stacks
access via the total count or this new NULL fencepost.
. Input params were simplified and generalized in both
oldproc_open() & close() to enable more than 1 PROCTAB
to be open simultaneously, which was required for get.
. The PROCPS_PIDS_logical_end enum was relocated after
the Item_table making the need to keep it synchronized
more apparent (if the table expands it's right there).
. The 'Public function' section of the source file was
subdivided into 1) the three basic required functions;
and 2) functions that can sometimes vary between APIs.
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-14 10:30:00 +05:30
|
|
|
procps_pids_unref;
|
|
|
|
|
procps_pids_get;
|
|
|
|
|
procps_pids_reap;
|
2015-08-19 10:30:00 +05:30
|
|
|
procps_pids_reset;
|
2015-10-01 10:30:00 +05:30
|
|
|
procps_pids_select;
|
2015-10-11 10:30:00 +05:30
|
|
|
procps_pids_sort;
|
2015-07-04 10:29:59 +05:30
|
|
|
procps_slabinfo_new;
|
|
|
|
|
procps_slabinfo_ref;
|
|
|
|
|
procps_slabinfo_unref;
|
library: normalize/standardize the i/f, <SLABINFO> api
Before this major redesign, the slabs interface likely
was our messiest 2nd generation attempt at opaqueness.
Beyond the standard 'new', 'ref' & 'unref', there were
a total of 12 exported functions. Now, there are four.
The 1st step was to remove several of those functions.
These were quick to go since they were not used (yet):
. procps_slabnode_count
. procps_slabnode_getname
. procps_slabnode_getstack
Then, the following were internalized so users needn't
be burdened with implementation details in the future:
. procps_slabinfo_read (renamed: read_slabinfo_failed)
. procps_slabnode_stacks_alloc (renamed: stacks_alloc)
Still others evolved into the minimal interface we had
strived for in the other upgraded 3rd generation APIs:
. procps_slabnode_get -----------> procps_slabinfo_get
. separate stack_alloc/fill --> procps_slabinfo_select
. separate stacks_alloc/fill ---> procps_slabinfo_reap
. procps_slabnode_stacks_sort --> procps_slabinfo_sort
------------------------------------------------------
Beyond those reductions, the major modifications were:
. This API tries to be as forgiving as possible and as
such won't throw errors when a caller request makes no
sense. For example, if a 'get' or 'select' requested a
SLABNODE item (with no current means to id that node),
results will be zero. By the same token, should 'reap'
include a global SLABS item (meaning those values will
be duplicated in *every* node stack) it'll be allowed.
. If the above behavior is undesired, a new #define of
ENFORCE_LOGICAL can be used to restrict certain items.
. Permission problems will now be caught at 'new' time
thanks to a priming 'read' call. That read also serves
to make DELTA values potentially useful at 1st access.
. Separate slab/slabnode enumerators were consolidated
into one, simplifying validation & the results struct.
. Several internal parameter checks were relaxed since
they were already checked by the caller. Besides if we
cannot trust our own code we might as well hang it up.
. That sort provision was made more efficient and will
offer the ascending choice, in addition to descending.
------------------------------------------------------
Lastly, some additional thoughts regarding the future:
. It would not be difficult to expand 'select' to also
accept a nodeid, or to clone it as 'select_node'. And,
should the same be extended to 'get', a results struct
could be returned instead of signed long accommodating
the extra data type(s) like a node name (string data).
. The 'get' function is not currently affected by that
define ENFORCE_LOGICAL. However, at some future point
perhaps -EINVAL would be more appropriate than a zero.
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
|
|
|
procps_slabinfo_get;
|
|
|
|
|
procps_slabinfo_reap;
|
|
|
|
|
procps_slabinfo_select;
|
|
|
|
|
procps_slabinfo_sort;
|
2015-06-20 03:13:02 +05:30
|
|
|
procps_stat_new;
|
|
|
|
|
procps_stat_ref;
|
|
|
|
|
procps_stat_unref;
|
library: improve/standardize one interface, <STAT> api
This commit represents a complete redesign of the stat
interface. Gone are the confusing 8 separate accessors
along with their 2 additional read functions. In their
place we have just 3 accessors, with no read required.
That old interface also suffered an inflexibility with
respect to structures. Now we deal with an unchanging
standard 'result' struct enabling future changes where
the binary interface will no longer need to be broken.
And gone is that former unnecessary typedef, used when
dealing with jiffies. Now the standard C type is used.
Our new API also adds some brand new functionality. If
a caller plans to employ successive 'select' or 'reap'
invocations, then delta values are available (which is
actually only what that top program is interested in).
At some future point a 'sort' function could be easily
introduced to complement the 'reap' function. However,
I saw no need for it at present and so it was omitted.
There were several design decisions which everyone may
not agree with. In support I'll offer these rationals:
. The 'get' function returns a signed long long result
which means a potential loss of some significance. But
I felt the ability to distinguish actual errors (minus
values) from true zero results were worth such a risk.
. The DELTA item enumerators were also made signed and
smaller than their parents. And they are intentionally
grouped as last so as to emphasize those distinctions.
. The SYS type items were excluded from the new 'reap'
function. It would not make sense to duplicate them in
each results stack. They're limited to 'get'/'select'.
. By the same token, some items (DELTA, etc.) will not
be allowed under that 'get' routine. That function was
already open to significant internal overhead (through
subsequent calls like in vmstat.c). That is why it has
been limited via 1 second between reads of /proc/stat.
Lastly, when we finally get around to documenting this
interface there's a real potential toe stubber when it
comes to the numa node portion. The libnuma.so doesn't
really provide any means to retrieve the active nodes.
Thus, any total reported by <stat> is just the highest
node number plus one, as reported by the numa library.
Any unused/inactive nodes are identified through these
. PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID
By the same token after the STAT_REAP_CPUS_ONLY 'reap'
. PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID
Reference(s):
http://www.freelists.org/post/procps/newlib-stat-interface
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
|
|
|
procps_stat_get;
|
|
|
|
|
procps_stat_reap;
|
|
|
|
|
procps_stat_select;
|
2016-07-24 10:30:00 +05:30
|
|
|
procps_stat_sort;
|
2015-06-29 17:39:59 +05:30
|
|
|
procps_uptime;
|
|
|
|
|
procps_uptime_sprint;
|
|
|
|
|
procps_uptime_sprint_short;
|
2015-06-20 03:13:02 +05:30
|
|
|
procps_vmstat_new;
|
|
|
|
|
procps_vmstat_ref;
|
|
|
|
|
procps_vmstat_unref;
|
|
|
|
|
procps_vmstat_get;
|
library: normalize/standardize interface, <VMSTAT> api
This interface represented a 2nd generation attempt at
the opaque newlib approach. In other words, it did not
involve the 1st generation 'chains'. Instead, 'stacks'
were employed. But the interface wasn't user friendly.
Users were required to create their own stacks, before
calling 'getstack' to retrieve multiple results with a
single call. Even worse, sometimes 'read' was required
before calling 'get' when working with single results.
So this commit represents the 3rd generation approach.
We eliminate the burden of 'read' and creating stacks.
Rather, beyond those standard 'new', 'ref' and 'unref'
functions, we'll offer just 'get' (single result) plus
a 'select' function (for multiple results in 1 stack).
And along the way, this commit vastly expands the data
extracted from /proc/vmstat. All values that currently
exist (and their delta equivalents) are now available.
Deltas were included for everything because there's no
real runtime costs beyond using a little extra memory.
The only problem is a lack of documentation for all of
those fields, as is reflected in the references below.
Oh well, maybe someday someone will dig through kernel
sources & finally plug that rather large document gap.
[ as an aside, rather than using a 'strcmp' approach ]
[ when parsing the /proc/vmstat file, as is found in ]
[ the <meminfo> module, we exploit those hash search ]
[ provisions that are found in the <search.h> header ]
Reference(s):
http://www.spinics.net/lists/linux-man/msg09096.html
http://www.linuxinsight.com/proc_vmstat.html
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-04 10:30:00 +05:30
|
|
|
procps_vmstat_select;
|
2016-08-05 10:30:00 +05:30
|
|
|
xtra_diskstats_get;
|
|
|
|
|
xtra_diskstats_val;
|
|
|
|
|
xtra_meminfo_get;
|
|
|
|
|
xtra_meminfo_val;
|
|
|
|
|
xtra_pids_val;
|
|
|
|
|
xtra_slabinfo_get;
|
|
|
|
|
xtra_slabinfo_val;
|
|
|
|
|
xtra_stat_get;
|
|
|
|
|
xtra_stat_val;
|
|
|
|
|
xtra_vmstat_get;
|
|
|
|
|
xtra_vmstat_val;
|
2011-11-05 17:59:54 +05:30
|
|
|
local:
|
|
|
|
|
*;
|
2003-01-15 16:22:39 +05:30
|
|
|
};
|
