emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
6eb0857531
procps/library/vmstat.c

1515 lines
65 KiB
C
Raw Normal View History

library: vmstat redesign now using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
/*
misc: Update the copyrights of files The copyrights of the source files were all out of date and were not the same format. This has been corrected. The source of the authors was examining the git log for each file. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 15:39:48 +05:30
* vmstat.c - virtual memory related definitions for libproc2
library: vmstat redesign now using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
*
misc: Update the copyrights of files The copyrights of the source files were all out of date and were not the same format. This has been corrected. The source of the authors was examining the git log for each file. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 15:39:48 +05:30
* Copyright © 2015-2023 Craig Small <csmall@dropbear.xyz>
* Copyright © 2016-2023 Jim Warner <james.warner@comcast.net>
* Copyright © 2011-2012 Sami Kerola <kerolasa@iki.fi>
* Copyright © 2003 Albert Cahalan
* Copyright © 1996 Charles Blake <cblake@bbn.com>
* Copyright © 1995 Martin Schulze <joey@infodrom.north.de>
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
*
library: vmstat redesign now using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +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
*/
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include <errno.h>
library: vmstat redesign now using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
#include <fcntl.h>
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
#include <search.h>
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#include <stdio.h>
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include <stdlib.h>
#include <string.h>
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
#include <time.h>
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include <unistd.h>
library: vmstat redesign now using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include <sys/stat.h>
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
#include <sys/types.h>
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
build-sys: Relocate library to library/ All the dependent programs needed to have their includes moved too Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 14:32:44 +05:30
#include "procps-private.h"
#include "vmstat.h"
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
library: size two read buffers with manifest constants The meminfo & vmstat file read buffers are now defined through symbolic constants next to the symbolic names. [ recent attention to the /proc/stat buffer size led ] [ to this (hopefully) better approach to definitions ] Reference(s): commit 81f4a6acdf204c5c898fa707e285cdbd2389150e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-06-29 10:30:00 +05:30
#define VMSTAT_FILE "/proc/vmstat"
#define VMSTAT_BUFF 8192
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
/* ------------------------------------------------------------- +
this provision can be used to help ensure that our Item_table |
was synchronized with the enumerators found in the associated |
header file. It's intended to be used locally (& temporarily) |
at least once at some point prior to publishing new releases! | */
// #define ITEMTABLE_DEBUG //----------------------------------- |
// ------------------------------------------------------------- +
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
/*
* Perhaps someday we'll all learn what is in these fields. But |
* that might require available linux documentation progressing |
* beyond a state that was acknowledged in the following thread |
*
* http://www.spinics.net/lists/linux-man/msg09096.html
*/
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
struct vmstat_data {
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 allocstall_dma;
unsigned long allocstall_dma32;
unsigned long allocstall_high;
unsigned long allocstall_movable;
unsigned long allocstall_normal;
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
unsigned long balloon_deflate;
unsigned long balloon_inflate;
unsigned long balloon_migrate;
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 compact_daemon_free_scanned;
unsigned long compact_daemon_migrate_scanned;
unsigned long compact_daemon_wake;
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
unsigned long compact_fail;
unsigned long compact_free_scanned;
unsigned long compact_isolated;
unsigned long compact_migrate_scanned;
unsigned long compact_stall;
unsigned long compact_success;
unsigned long drop_pagecache;
unsigned long drop_slab;
unsigned long htlb_buddy_alloc_fail;
unsigned long htlb_buddy_alloc_success;
unsigned long kswapd_high_wmark_hit_quickly;
unsigned long kswapd_inodesteal;
unsigned long kswapd_low_wmark_hit_quickly;
unsigned long nr_active_anon;
unsigned long nr_active_file;
unsigned long nr_anon_pages;
unsigned long nr_anon_transparent_hugepages;
unsigned long nr_bounce;
unsigned long nr_dirtied;
unsigned long nr_dirty;
unsigned long nr_dirty_background_threshold;
unsigned long nr_dirty_threshold;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long nr_file_hugepages;
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
unsigned long nr_file_pages;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long nr_file_pmdmapped;
unsigned long nr_foll_pin_acquired;
unsigned long nr_foll_pin_released;
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
unsigned long nr_free_cma;
unsigned long nr_free_pages;
unsigned long nr_inactive_anon;
unsigned long nr_inactive_file;
unsigned long nr_isolated_anon;
unsigned long nr_isolated_file;
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 nr_kernel_misc_reclaimable;
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
unsigned long nr_kernel_stack;
unsigned long nr_mapped;
unsigned long nr_mlock;
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 nr_page_table_pages;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long nr_shadow_call_stack;
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
unsigned long nr_shmem;
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 nr_shmem_hugepages;
unsigned long nr_shmem_pmdmapped;
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
unsigned long nr_slab_reclaimable;
unsigned long nr_slab_unreclaimable;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
/* nr_tlb_local_flush_all; CONFIG_DEBUG_TLBFLUSH only */
/* nr_tlb_local_flush_one; CONFIG_DEBUG_TLBFLUSH only */
/* nr_tlb_remote_flush; CONFIG_DEBUG_TLBFLUSH only */
/* nr_tlb_remote_flush_received; CONFIG_DEBUG_TLBFLUSH only */
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
unsigned long nr_unevictable;
unsigned long nr_unstable;
unsigned long nr_vmscan_immediate_reclaim;
unsigned long nr_vmscan_write;
unsigned long nr_writeback;
unsigned long nr_writeback_temp;
unsigned long nr_written;
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 nr_zone_active_anon;
unsigned long nr_zone_active_file;
unsigned long nr_zone_inactive_anon;
unsigned long nr_zone_inactive_file;
unsigned long nr_zone_unevictable;
unsigned long nr_zone_write_pending;
unsigned long nr_zspages;
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
unsigned long numa_foreign;
unsigned long numa_hint_faults;
unsigned long numa_hint_faults_local;
unsigned long numa_hit;
unsigned long numa_huge_pte_updates;
unsigned long numa_interleave;
unsigned long numa_local;
unsigned long numa_miss;
unsigned long numa_other;
unsigned long numa_pages_migrated;
unsigned long numa_pte_updates;
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 oom_kill;
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
unsigned long pageoutrun;
unsigned long pgactivate;
unsigned long pgalloc_dma;
unsigned long pgalloc_dma32;
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 pgalloc_high;
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
unsigned long pgalloc_movable;
unsigned long pgalloc_normal;
unsigned long pgdeactivate;
unsigned long pgfault;
unsigned long pgfree;
unsigned long pginodesteal;
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 pglazyfree;
unsigned long pglazyfreed;
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
unsigned long pgmajfault;
unsigned long pgmigrate_fail;
unsigned long pgmigrate_success;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
unsigned long pgpgin;
unsigned long pgpgout;
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 pgrefill;
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
unsigned long pgrotated;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long pgscan_anon;
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 pgscan_direct;
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
unsigned long pgscan_direct_throttle;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long pgscan_file;
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 pgscan_kswapd;
unsigned long pgskip_dma;
unsigned long pgskip_dma32;
unsigned long pgskip_high;
unsigned long pgskip_movable;
unsigned long pgskip_normal;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long pgsteal_anon;
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 pgsteal_direct;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long pgsteal_file;
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 pgsteal_kswapd;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
unsigned long pswpin;
unsigned long pswpout;
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
unsigned long slabs_scanned;
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 swap_ra;
unsigned long swap_ra_hit;
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
unsigned long thp_collapse_alloc;
unsigned long thp_collapse_alloc_failed;
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 thp_deferred_split_page;
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
unsigned long thp_fault_alloc;
unsigned long thp_fault_fallback;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long thp_fault_fallback_charge;
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 thp_file_alloc;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
unsigned long thp_file_fallback;
unsigned long thp_file_fallback_charge;
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 thp_file_mapped;
unsigned long thp_split_page;
unsigned long thp_split_page_failed;
unsigned long thp_split_pmd;
unsigned long thp_split_pud;
unsigned long thp_swpout;
unsigned long thp_swpout_fallback;
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
unsigned long thp_zero_page_alloc;
unsigned long thp_zero_page_alloc_failed;
unsigned long unevictable_pgs_cleared;
unsigned long unevictable_pgs_culled;
unsigned long unevictable_pgs_mlocked;
unsigned long unevictable_pgs_munlocked;
unsigned long unevictable_pgs_rescued;
unsigned long unevictable_pgs_scanned;
unsigned long unevictable_pgs_stranded;
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
/* vmacache_find_calls; CONFIG_DEBUG_VM_VMACACHE only */
/* vmacache_find_hits; CONFIG_DEBUG_VM_VMACACHE only */
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
unsigned long workingset_activate;
unsigned long workingset_nodereclaim;
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 workingset_nodes;
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
unsigned long workingset_refault;
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 workingset_restore;
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
unsigned long zone_reclaim_failed;
};
struct vmstat_hist {
struct vmstat_data new;
struct vmstat_data old;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
};
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
struct stacks_extent {
int ext_numstacks;
struct stacks_extent *next;
struct vmstat_stack **stacks;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
};
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info {
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
int refcount;
int vmstat_fd;
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
struct vmstat_hist hist;
int numitems;
enum vmstat_item *items;
struct stacks_extent *extents;
struct hsearch_data hashtab;
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
struct vmstat_result get_this;
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
time_t sav_secs;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
};
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
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
#define setNAME(e) set_vmstat_ ## e
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
#define setDECL(e) static void setNAME(e) \
(struct vmstat_result *R, struct vmstat_hist *H)
// regular assignment
library: strictly cosmetic change involving whitespace This patch just standardizes/normalizes the whitespace employed within a couple of nearly identical #defines. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-12-12 10:30:00 +05:30
#define REG_set(e,x) setDECL(e) { R->result.ul_int = H->new. x; }
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
// delta assignment
library: strictly cosmetic change involving whitespace This patch just standardizes/normalizes the whitespace employed within a couple of nearly identical #defines. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-12-12 10:30:00 +05:30
#define HST_set(e,x) setDECL(e) { R->result.sl_int = ( H->new. x - H->old. x ); }
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
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; }
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
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
REG_set(ALLOCSTALL_DMA, allocstall_dma)
REG_set(ALLOCSTALL_DMA32, allocstall_dma32)
REG_set(ALLOCSTALL_HIGH, allocstall_high)
REG_set(ALLOCSTALL_MOVABLE, allocstall_movable)
REG_set(ALLOCSTALL_NORMAL, allocstall_normal)
REG_set(BALLOON_DEFLATE, balloon_deflate)
REG_set(BALLOON_INFLATE, balloon_inflate)
REG_set(BALLOON_MIGRATE, balloon_migrate)
REG_set(COMPACT_DAEMON_FREE_SCANNED, compact_daemon_free_scanned)
REG_set(COMPACT_DAEMON_MIGRATE_SCANNED, compact_daemon_migrate_scanned)
REG_set(COMPACT_DAEMON_WAKE, compact_daemon_wake)
REG_set(COMPACT_FAIL, compact_fail)
REG_set(COMPACT_FREE_SCANNED, compact_free_scanned)
REG_set(COMPACT_ISOLATED, compact_isolated)
REG_set(COMPACT_MIGRATE_SCANNED, compact_migrate_scanned)
REG_set(COMPACT_STALL, compact_stall)
REG_set(COMPACT_SUCCESS, compact_success)
REG_set(DROP_PAGECACHE, drop_pagecache)
REG_set(DROP_SLAB, drop_slab)
REG_set(HTLB_BUDDY_ALLOC_FAIL, htlb_buddy_alloc_fail)
REG_set(HTLB_BUDDY_ALLOC_SUCCESS, htlb_buddy_alloc_success)
REG_set(KSWAPD_HIGH_WMARK_HIT_QUICKLY, kswapd_high_wmark_hit_quickly)
REG_set(KSWAPD_INODESTEAL, kswapd_inodesteal)
REG_set(KSWAPD_LOW_WMARK_HIT_QUICKLY, kswapd_low_wmark_hit_quickly)
REG_set(NR_ACTIVE_ANON, nr_active_anon)
REG_set(NR_ACTIVE_FILE, nr_active_file)
REG_set(NR_ANON_PAGES, nr_anon_pages)
REG_set(NR_ANON_TRANSPARENT_HUGEPAGES, nr_anon_transparent_hugepages)
REG_set(NR_BOUNCE, nr_bounce)
REG_set(NR_DIRTIED, nr_dirtied)
REG_set(NR_DIRTY, nr_dirty)
REG_set(NR_DIRTY_BACKGROUND_THRESHOLD, nr_dirty_background_threshold)
REG_set(NR_DIRTY_THRESHOLD, nr_dirty_threshold)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(NR_FILE_HUGEPAGES, nr_file_hugepages)
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
REG_set(NR_FILE_PAGES, nr_file_pages)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(NR_FILE_PMDMAPPED, nr_file_pmdmapped)
REG_set(NR_FOLL_PIN_ACQUIRED, nr_foll_pin_acquired)
REG_set(NR_FOLL_PIN_RELEASED, nr_foll_pin_released)
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
REG_set(NR_FREE_CMA, nr_free_cma)
REG_set(NR_FREE_PAGES, nr_free_pages)
REG_set(NR_INACTIVE_ANON, nr_inactive_anon)
REG_set(NR_INACTIVE_FILE, nr_inactive_file)
REG_set(NR_ISOLATED_ANON, nr_isolated_anon)
REG_set(NR_ISOLATED_FILE, nr_isolated_file)
REG_set(NR_KERNEL_MISC_RECLAIMABLE, nr_kernel_misc_reclaimable)
REG_set(NR_KERNEL_STACK, nr_kernel_stack)
REG_set(NR_MAPPED, nr_mapped)
REG_set(NR_MLOCK, nr_mlock)
REG_set(NR_PAGE_TABLE_PAGES, nr_page_table_pages)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(NR_SHADOW_CALL_STACK, nr_shadow_call_stack)
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
REG_set(NR_SHMEM, nr_shmem)
REG_set(NR_SHMEM_HUGEPAGES, nr_shmem_hugepages)
REG_set(NR_SHMEM_PMDMAPPED, nr_shmem_pmdmapped)
REG_set(NR_SLAB_RECLAIMABLE, nr_slab_reclaimable)
REG_set(NR_SLAB_UNRECLAIMABLE, nr_slab_unreclaimable)
REG_set(NR_UNEVICTABLE, nr_unevictable)
REG_set(NR_UNSTABLE, nr_unstable)
REG_set(NR_VMSCAN_IMMEDIATE_RECLAIM, nr_vmscan_immediate_reclaim)
REG_set(NR_VMSCAN_WRITE, nr_vmscan_write)
REG_set(NR_WRITEBACK, nr_writeback)
REG_set(NR_WRITEBACK_TEMP, nr_writeback_temp)
REG_set(NR_WRITTEN, nr_written)
REG_set(NR_ZONE_ACTIVE_ANON, nr_zone_active_anon)
REG_set(NR_ZONE_ACTIVE_FILE, nr_zone_active_file)
REG_set(NR_ZONE_INACTIVE_ANON, nr_zone_inactive_anon)
REG_set(NR_ZONE_INACTIVE_FILE, nr_zone_inactive_file)
REG_set(NR_ZONE_UNEVICTABLE, nr_zone_unevictable)
REG_set(NR_ZONE_WRITE_PENDING, nr_zone_write_pending)
REG_set(NR_ZSPAGES, nr_zspages)
REG_set(NUMA_FOREIGN, numa_foreign)
REG_set(NUMA_HINT_FAULTS, numa_hint_faults)
REG_set(NUMA_HINT_FAULTS_LOCAL, numa_hint_faults_local)
REG_set(NUMA_HIT, numa_hit)
REG_set(NUMA_HUGE_PTE_UPDATES, numa_huge_pte_updates)
REG_set(NUMA_INTERLEAVE, numa_interleave)
REG_set(NUMA_LOCAL, numa_local)
REG_set(NUMA_MISS, numa_miss)
REG_set(NUMA_OTHER, numa_other)
REG_set(NUMA_PAGES_MIGRATED, numa_pages_migrated)
REG_set(NUMA_PTE_UPDATES, numa_pte_updates)
REG_set(OOM_KILL, oom_kill)
REG_set(PAGEOUTRUN, pageoutrun)
REG_set(PGACTIVATE, pgactivate)
REG_set(PGALLOC_DMA, pgalloc_dma)
REG_set(PGALLOC_DMA32, pgalloc_dma32)
REG_set(PGALLOC_HIGH, pgalloc_high)
REG_set(PGALLOC_MOVABLE, pgalloc_movable)
REG_set(PGALLOC_NORMAL, pgalloc_normal)
REG_set(PGDEACTIVATE, pgdeactivate)
REG_set(PGFAULT, pgfault)
REG_set(PGFREE, pgfree)
REG_set(PGINODESTEAL, pginodesteal)
REG_set(PGLAZYFREE, pglazyfree)
REG_set(PGLAZYFREED, pglazyfreed)
REG_set(PGMAJFAULT, pgmajfault)
REG_set(PGMIGRATE_FAIL, pgmigrate_fail)
REG_set(PGMIGRATE_SUCCESS, pgmigrate_success)
REG_set(PGPGIN, pgpgin)
REG_set(PGPGOUT, pgpgout)
REG_set(PGREFILL, pgrefill)
REG_set(PGROTATED, pgrotated)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(PGSCAN_ANON, pgscan_anon)
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
REG_set(PGSCAN_DIRECT, pgscan_direct)
REG_set(PGSCAN_DIRECT_THROTTLE, pgscan_direct_throttle)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(PGSCAN_FILE, pgscan_file)
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
REG_set(PGSCAN_KSWAPD, pgscan_kswapd)
REG_set(PGSKIP_DMA, pgskip_dma)
REG_set(PGSKIP_DMA32, pgskip_dma32)
REG_set(PGSKIP_HIGH, pgskip_high)
REG_set(PGSKIP_MOVABLE, pgskip_movable)
REG_set(PGSKIP_NORMAL, pgskip_normal)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(PGSTEAL_ANON, pgsteal_anon)
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
REG_set(PGSTEAL_DIRECT, pgsteal_direct)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(PGSTEAL_FILE, pgsteal_file)
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
REG_set(PGSTEAL_KSWAPD, pgsteal_kswapd)
REG_set(PSWPIN, pswpin)
REG_set(PSWPOUT, pswpout)
REG_set(SLABS_SCANNED, slabs_scanned)
REG_set(SWAP_RA, swap_ra)
REG_set(SWAP_RA_HIT, swap_ra_hit)
REG_set(THP_COLLAPSE_ALLOC, thp_collapse_alloc)
REG_set(THP_COLLAPSE_ALLOC_FAILED, thp_collapse_alloc_failed)
REG_set(THP_DEFERRED_SPLIT_PAGE, thp_deferred_split_page)
REG_set(THP_FAULT_ALLOC, thp_fault_alloc)
REG_set(THP_FAULT_FALLBACK, thp_fault_fallback)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(THP_FAULT_FALLBACK_CHARGE, thp_fault_fallback_charge)
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
REG_set(THP_FILE_ALLOC, thp_file_alloc)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
REG_set(THP_FILE_FALLBACK, thp_file_fallback)
REG_set(THP_FILE_FALLBACK_CHARGE, thp_file_fallback_charge)
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
REG_set(THP_FILE_MAPPED, thp_file_mapped)
REG_set(THP_SPLIT_PAGE, thp_split_page)
REG_set(THP_SPLIT_PAGE_FAILED, thp_split_page_failed)
REG_set(THP_SPLIT_PMD, thp_split_pmd)
REG_set(THP_SPLIT_PUD, thp_split_pud)
REG_set(THP_SWPOUT, thp_swpout)
REG_set(THP_SWPOUT_FALLBACK, thp_swpout_fallback)
REG_set(THP_ZERO_PAGE_ALLOC, thp_zero_page_alloc)
REG_set(THP_ZERO_PAGE_ALLOC_FAILED, thp_zero_page_alloc_failed)
REG_set(UNEVICTABLE_PGS_CLEARED, unevictable_pgs_cleared)
REG_set(UNEVICTABLE_PGS_CULLED, unevictable_pgs_culled)
REG_set(UNEVICTABLE_PGS_MLOCKED, unevictable_pgs_mlocked)
REG_set(UNEVICTABLE_PGS_MUNLOCKED, unevictable_pgs_munlocked)
REG_set(UNEVICTABLE_PGS_RESCUED, unevictable_pgs_rescued)
REG_set(UNEVICTABLE_PGS_SCANNED, unevictable_pgs_scanned)
REG_set(UNEVICTABLE_PGS_STRANDED, unevictable_pgs_stranded)
REG_set(WORKINGSET_ACTIVATE, workingset_activate)
REG_set(WORKINGSET_NODERECLAIM, workingset_nodereclaim)
REG_set(WORKINGSET_NODES, workingset_nodes)
REG_set(WORKINGSET_REFAULT, workingset_refault)
REG_set(WORKINGSET_RESTORE, workingset_restore)
REG_set(ZONE_RECLAIM_FAILED, zone_reclaim_failed)
HST_set(DELTA_ALLOCSTALL_DMA, allocstall_dma)
HST_set(DELTA_ALLOCSTALL_DMA32, allocstall_dma32)
HST_set(DELTA_ALLOCSTALL_HIGH, allocstall_high)
HST_set(DELTA_ALLOCSTALL_MOVABLE, allocstall_movable)
HST_set(DELTA_ALLOCSTALL_NORMAL, allocstall_normal)
HST_set(DELTA_BALLOON_DEFLATE, balloon_deflate)
HST_set(DELTA_BALLOON_INFLATE, balloon_inflate)
HST_set(DELTA_BALLOON_MIGRATE, balloon_migrate)
HST_set(DELTA_COMPACT_DAEMON_FREE_SCANNED, compact_daemon_free_scanned)
HST_set(DELTA_COMPACT_DAEMON_MIGRATE_SCANNED, compact_daemon_migrate_scanned)
HST_set(DELTA_COMPACT_DAEMON_WAKE, compact_daemon_wake)
HST_set(DELTA_COMPACT_FAIL, compact_fail)
HST_set(DELTA_COMPACT_FREE_SCANNED, compact_free_scanned)
HST_set(DELTA_COMPACT_ISOLATED, compact_isolated)
HST_set(DELTA_COMPACT_MIGRATE_SCANNED, compact_migrate_scanned)
HST_set(DELTA_COMPACT_STALL, compact_stall)
HST_set(DELTA_COMPACT_SUCCESS, compact_success)
HST_set(DELTA_DROP_PAGECACHE, drop_pagecache)
HST_set(DELTA_DROP_SLAB, drop_slab)
HST_set(DELTA_HTLB_BUDDY_ALLOC_FAIL, htlb_buddy_alloc_fail)
HST_set(DELTA_HTLB_BUDDY_ALLOC_SUCCESS, htlb_buddy_alloc_success)
HST_set(DELTA_KSWAPD_HIGH_WMARK_HIT_QUICKLY, kswapd_high_wmark_hit_quickly)
HST_set(DELTA_KSWAPD_INODESTEAL, kswapd_inodesteal)
HST_set(DELTA_KSWAPD_LOW_WMARK_HIT_QUICKLY, kswapd_low_wmark_hit_quickly)
HST_set(DELTA_NR_ACTIVE_ANON, nr_active_anon)
HST_set(DELTA_NR_ACTIVE_FILE, nr_active_file)
HST_set(DELTA_NR_ANON_PAGES, nr_anon_pages)
HST_set(DELTA_NR_ANON_TRANSPARENT_HUGEPAGES, nr_anon_transparent_hugepages)
HST_set(DELTA_NR_BOUNCE, nr_bounce)
HST_set(DELTA_NR_DIRTIED, nr_dirtied)
HST_set(DELTA_NR_DIRTY, nr_dirty)
HST_set(DELTA_NR_DIRTY_BACKGROUND_THRESHOLD, nr_dirty_background_threshold)
HST_set(DELTA_NR_DIRTY_THRESHOLD, nr_dirty_threshold)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_NR_FILE_HUGEPAGES, nr_file_hugepages)
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_NR_FILE_PAGES, nr_file_pages)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_NR_FILE_PMDMAPPED, nr_file_pmdmapped)
HST_set(DELTA_NR_FOLL_PIN_ACQUIRED, nr_foll_pin_acquired)
HST_set(DELTA_NR_FOLL_PIN_RELEASED, nr_foll_pin_released)
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_NR_FREE_CMA, nr_free_cma)
HST_set(DELTA_NR_FREE_PAGES, nr_free_pages)
HST_set(DELTA_NR_INACTIVE_ANON, nr_inactive_anon)
HST_set(DELTA_NR_INACTIVE_FILE, nr_inactive_file)
HST_set(DELTA_NR_ISOLATED_ANON, nr_isolated_anon)
HST_set(DELTA_NR_ISOLATED_FILE, nr_isolated_file)
HST_set(DELTA_NR_KERNEL_MISC_RECLAIMABLE, nr_kernel_misc_reclaimable)
HST_set(DELTA_NR_KERNEL_STACK, nr_kernel_stack)
HST_set(DELTA_NR_MAPPED, nr_mapped)
HST_set(DELTA_NR_MLOCK, nr_mlock)
HST_set(DELTA_NR_PAGE_TABLE_PAGES, nr_page_table_pages)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_NR_SHADOW_CALL_STACK, nr_shadow_call_stack)
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_NR_SHMEM, nr_shmem)
HST_set(DELTA_NR_SHMEM_HUGEPAGES, nr_shmem_hugepages)
HST_set(DELTA_NR_SHMEM_PMDMAPPED, nr_shmem_pmdmapped)
HST_set(DELTA_NR_SLAB_RECLAIMABLE, nr_slab_reclaimable)
HST_set(DELTA_NR_SLAB_UNRECLAIMABLE, nr_slab_unreclaimable)
HST_set(DELTA_NR_UNEVICTABLE, nr_unevictable)
HST_set(DELTA_NR_UNSTABLE, nr_unstable)
HST_set(DELTA_NR_VMSCAN_IMMEDIATE_RECLAIM, nr_vmscan_immediate_reclaim)
HST_set(DELTA_NR_VMSCAN_WRITE, nr_vmscan_write)
HST_set(DELTA_NR_WRITEBACK, nr_writeback)
HST_set(DELTA_NR_WRITEBACK_TEMP, nr_writeback_temp)
HST_set(DELTA_NR_WRITTEN, nr_written)
HST_set(DELTA_NR_ZONE_ACTIVE_ANON, nr_zone_active_anon)
HST_set(DELTA_NR_ZONE_ACTIVE_FILE, nr_zone_active_file)
HST_set(DELTA_NR_ZONE_INACTIVE_ANON, nr_zone_inactive_anon)
HST_set(DELTA_NR_ZONE_INACTIVE_FILE, nr_zone_inactive_file)
HST_set(DELTA_NR_ZONE_UNEVICTABLE, nr_zone_unevictable)
HST_set(DELTA_NR_ZONE_WRITE_PENDING, nr_zone_write_pending)
HST_set(DELTA_NR_ZSPAGES, nr_zspages)
HST_set(DELTA_NUMA_FOREIGN, numa_foreign)
HST_set(DELTA_NUMA_HINT_FAULTS, numa_hint_faults)
HST_set(DELTA_NUMA_HINT_FAULTS_LOCAL, numa_hint_faults_local)
HST_set(DELTA_NUMA_HIT, numa_hit)
HST_set(DELTA_NUMA_HUGE_PTE_UPDATES, numa_huge_pte_updates)
HST_set(DELTA_NUMA_INTERLEAVE, numa_interleave)
HST_set(DELTA_NUMA_LOCAL, numa_local)
HST_set(DELTA_NUMA_MISS, numa_miss)
HST_set(DELTA_NUMA_OTHER, numa_other)
HST_set(DELTA_NUMA_PAGES_MIGRATED, numa_pages_migrated)
HST_set(DELTA_NUMA_PTE_UPDATES, numa_pte_updates)
HST_set(DELTA_OOM_KILL, oom_kill)
HST_set(DELTA_PAGEOUTRUN, pageoutrun)
HST_set(DELTA_PGACTIVATE, pgactivate)
HST_set(DELTA_PGALLOC_DMA, pgalloc_dma)
HST_set(DELTA_PGALLOC_DMA32, pgalloc_dma32)
HST_set(DELTA_PGALLOC_HIGH, pgalloc_high)
HST_set(DELTA_PGALLOC_MOVABLE, pgalloc_movable)
HST_set(DELTA_PGALLOC_NORMAL, pgalloc_normal)
HST_set(DELTA_PGDEACTIVATE, pgdeactivate)
HST_set(DELTA_PGFAULT, pgfault)
HST_set(DELTA_PGFREE, pgfree)
HST_set(DELTA_PGINODESTEAL, pginodesteal)
HST_set(DELTA_PGLAZYFREE, pglazyfree)
HST_set(DELTA_PGLAZYFREED, pglazyfreed)
HST_set(DELTA_PGMAJFAULT, pgmajfault)
HST_set(DELTA_PGMIGRATE_FAIL, pgmigrate_fail)
HST_set(DELTA_PGMIGRATE_SUCCESS, pgmigrate_success)
HST_set(DELTA_PGPGIN, pgpgin)
HST_set(DELTA_PGPGOUT, pgpgout)
HST_set(DELTA_PGREFILL, pgrefill)
HST_set(DELTA_PGROTATED, pgrotated)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_PGSCAN_ANON, pgscan_anon)
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_PGSCAN_DIRECT, pgscan_direct)
HST_set(DELTA_PGSCAN_DIRECT_THROTTLE, pgscan_direct_throttle)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_PGSCAN_FILE, pgscan_file)
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_PGSCAN_KSWAPD, pgscan_kswapd)
HST_set(DELTA_PGSKIP_DMA, pgskip_dma)
HST_set(DELTA_PGSKIP_DMA32, pgskip_dma32)
HST_set(DELTA_PGSKIP_HIGH, pgskip_high)
HST_set(DELTA_PGSKIP_MOVABLE, pgskip_movable)
HST_set(DELTA_PGSKIP_NORMAL, pgskip_normal)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_PGSTEAL_ANON, pgsteal_anon)
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_PGSTEAL_DIRECT, pgsteal_direct)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_PGSTEAL_FILE, pgsteal_file)
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_PGSTEAL_KSWAPD, pgsteal_kswapd)
HST_set(DELTA_PSWPIN, pswpin)
HST_set(DELTA_PSWPOUT, pswpout)
HST_set(DELTA_SLABS_SCANNED, slabs_scanned)
HST_set(DELTA_SWAP_RA, swap_ra)
HST_set(DELTA_SWAP_RA_HIT, swap_ra_hit)
HST_set(DELTA_THP_COLLAPSE_ALLOC, thp_collapse_alloc)
HST_set(DELTA_THP_COLLAPSE_ALLOC_FAILED, thp_collapse_alloc_failed)
HST_set(DELTA_THP_DEFERRED_SPLIT_PAGE, thp_deferred_split_page)
HST_set(DELTA_THP_FAULT_ALLOC, thp_fault_alloc)
HST_set(DELTA_THP_FAULT_FALLBACK, thp_fault_fallback)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_THP_FAULT_FALLBACK_CHARGE, thp_fault_fallback_charge)
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_THP_FILE_ALLOC, thp_file_alloc)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
HST_set(DELTA_THP_FILE_FALLBACK, thp_file_fallback)
HST_set(DELTA_THP_FILE_FALLBACK_CHARGE, thp_file_fallback_charge)
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_THP_FILE_MAPPED, thp_file_mapped)
HST_set(DELTA_THP_SPLIT_PAGE, thp_split_page)
HST_set(DELTA_THP_SPLIT_PAGE_FAILED, thp_split_page_failed)
HST_set(DELTA_THP_SPLIT_PMD, thp_split_pmd)
HST_set(DELTA_THP_SPLIT_PUD, thp_split_pud)
HST_set(DELTA_THP_SWPOUT, thp_swpout)
HST_set(DELTA_THP_SWPOUT_FALLBACK, thp_swpout_fallback)
HST_set(DELTA_THP_ZERO_PAGE_ALLOC, thp_zero_page_alloc)
HST_set(DELTA_THP_ZERO_PAGE_ALLOC_FAILED, thp_zero_page_alloc_failed)
HST_set(DELTA_UNEVICTABLE_PGS_CLEARED, unevictable_pgs_cleared)
HST_set(DELTA_UNEVICTABLE_PGS_CULLED, unevictable_pgs_culled)
HST_set(DELTA_UNEVICTABLE_PGS_MLOCKED, unevictable_pgs_mlocked)
HST_set(DELTA_UNEVICTABLE_PGS_MUNLOCKED, unevictable_pgs_munlocked)
HST_set(DELTA_UNEVICTABLE_PGS_RESCUED, unevictable_pgs_rescued)
HST_set(DELTA_UNEVICTABLE_PGS_SCANNED, unevictable_pgs_scanned)
HST_set(DELTA_UNEVICTABLE_PGS_STRANDED, unevictable_pgs_stranded)
HST_set(DELTA_WORKINGSET_ACTIVATE, workingset_activate)
HST_set(DELTA_WORKINGSET_NODERECLAIM, workingset_nodereclaim)
HST_set(DELTA_WORKINGSET_NODES, workingset_nodes)
HST_set(DELTA_WORKINGSET_REFAULT, workingset_refault)
HST_set(DELTA_WORKINGSET_RESTORE, workingset_restore)
HST_set(DELTA_ZONE_RECLAIM_FAILED, zone_reclaim_failed)
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
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#undef setDECL
#undef REG_set
#undef HST_set
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
// ___ Controlling Table ||||||||||||||||||||||||||||||||||||||||||||||||||||||
typedef void (*SET_t)(struct vmstat_result *, struct vmstat_hist *);
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
#ifdef ITEMTABLE_DEBUG
#define RS(e) (SET_t)setNAME(e), VMSTAT_ ## e, STRINGIFY(VMSTAT_ ## e)
#else
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
#define RS(e) (SET_t)setNAME(e)
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-10 10:30:00 +05:30
#endif
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
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#define TS(t) STRINGIFY(t)
#define TS_noop ""
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
/*
* Need it be said?
* This table must be kept in the exact same order as
* those 'enum vmstat_item' guys ! */
static struct {
SET_t setsfunc; // the actual result setting routine
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
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
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
char *type2str; // the result type as a string value
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
} Item_table[] = {
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
/* setsfunc type2str
----------------------------------------- ---------- */
{ RS(noop), TS_noop },
{ RS(extra), TS_noop },
{ RS(ALLOCSTALL_DMA), TS(ul_int) },
{ RS(ALLOCSTALL_DMA32), TS(ul_int) },
{ RS(ALLOCSTALL_HIGH), TS(ul_int) },
{ RS(ALLOCSTALL_MOVABLE), TS(ul_int) },
{ RS(ALLOCSTALL_NORMAL), TS(ul_int) },
{ RS(BALLOON_DEFLATE), TS(ul_int) },
{ RS(BALLOON_INFLATE), TS(ul_int) },
{ RS(BALLOON_MIGRATE), TS(ul_int) },
{ RS(COMPACT_DAEMON_FREE_SCANNED), TS(ul_int) },
{ RS(COMPACT_DAEMON_MIGRATE_SCANNED), TS(ul_int) },
{ RS(COMPACT_DAEMON_WAKE), TS(ul_int) },
{ RS(COMPACT_FAIL), TS(ul_int) },
{ RS(COMPACT_FREE_SCANNED), TS(ul_int) },
{ RS(COMPACT_ISOLATED), TS(ul_int) },
{ RS(COMPACT_MIGRATE_SCANNED), TS(ul_int) },
{ RS(COMPACT_STALL), TS(ul_int) },
{ RS(COMPACT_SUCCESS), TS(ul_int) },
{ RS(DROP_PAGECACHE), TS(ul_int) },
{ RS(DROP_SLAB), TS(ul_int) },
{ RS(HTLB_BUDDY_ALLOC_FAIL), TS(ul_int) },
{ RS(HTLB_BUDDY_ALLOC_SUCCESS), TS(ul_int) },
{ RS(KSWAPD_HIGH_WMARK_HIT_QUICKLY), TS(ul_int) },
{ RS(KSWAPD_INODESTEAL), TS(ul_int) },
{ RS(KSWAPD_LOW_WMARK_HIT_QUICKLY), TS(ul_int) },
{ RS(NR_ACTIVE_ANON), TS(ul_int) },
{ RS(NR_ACTIVE_FILE), TS(ul_int) },
{ RS(NR_ANON_PAGES), TS(ul_int) },
{ RS(NR_ANON_TRANSPARENT_HUGEPAGES), TS(ul_int) },
{ RS(NR_BOUNCE), TS(ul_int) },
{ RS(NR_DIRTIED), TS(ul_int) },
{ RS(NR_DIRTY), TS(ul_int) },
{ RS(NR_DIRTY_BACKGROUND_THRESHOLD), TS(ul_int) },
{ RS(NR_DIRTY_THRESHOLD), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(NR_FILE_HUGEPAGES), 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(NR_FILE_PAGES), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(NR_FILE_PMDMAPPED), TS(ul_int) },
{ RS(NR_FOLL_PIN_ACQUIRED), TS(ul_int) },
{ RS(NR_FOLL_PIN_RELEASED), 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(NR_FREE_CMA), TS(ul_int) },
{ RS(NR_FREE_PAGES), TS(ul_int) },
{ RS(NR_INACTIVE_ANON), TS(ul_int) },
{ RS(NR_INACTIVE_FILE), TS(ul_int) },
{ RS(NR_ISOLATED_ANON), TS(ul_int) },
{ RS(NR_ISOLATED_FILE), TS(ul_int) },
{ RS(NR_KERNEL_MISC_RECLAIMABLE), TS(ul_int) },
{ RS(NR_KERNEL_STACK), TS(ul_int) },
{ RS(NR_MAPPED), TS(ul_int) },
{ RS(NR_MLOCK), TS(ul_int) },
{ RS(NR_PAGE_TABLE_PAGES), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(NR_SHADOW_CALL_STACK), 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(NR_SHMEM), TS(ul_int) },
{ RS(NR_SHMEM_HUGEPAGES), TS(ul_int) },
{ RS(NR_SHMEM_PMDMAPPED), TS(ul_int) },
{ RS(NR_SLAB_RECLAIMABLE), TS(ul_int) },
{ RS(NR_SLAB_UNRECLAIMABLE), TS(ul_int) },
{ RS(NR_UNEVICTABLE), TS(ul_int) },
{ RS(NR_UNSTABLE), TS(ul_int) },
{ RS(NR_VMSCAN_IMMEDIATE_RECLAIM), TS(ul_int) },
{ RS(NR_VMSCAN_WRITE), TS(ul_int) },
{ RS(NR_WRITEBACK), TS(ul_int) },
{ RS(NR_WRITEBACK_TEMP), TS(ul_int) },
{ RS(NR_WRITTEN), TS(ul_int) },
{ RS(NR_ZONE_ACTIVE_ANON), TS(ul_int) },
{ RS(NR_ZONE_ACTIVE_FILE), TS(ul_int) },
{ RS(NR_ZONE_INACTIVE_ANON), TS(ul_int) },
{ RS(NR_ZONE_INACTIVE_FILE), TS(ul_int) },
{ RS(NR_ZONE_UNEVICTABLE), TS(ul_int) },
{ RS(NR_ZONE_WRITE_PENDING), TS(ul_int) },
{ RS(NR_ZSPAGES), TS(ul_int) },
{ RS(NUMA_FOREIGN), TS(ul_int) },
{ RS(NUMA_HINT_FAULTS), TS(ul_int) },
{ RS(NUMA_HINT_FAULTS_LOCAL), TS(ul_int) },
{ RS(NUMA_HIT), TS(ul_int) },
{ RS(NUMA_HUGE_PTE_UPDATES), TS(ul_int) },
{ RS(NUMA_INTERLEAVE), TS(ul_int) },
{ RS(NUMA_LOCAL), TS(ul_int) },
{ RS(NUMA_MISS), TS(ul_int) },
{ RS(NUMA_OTHER), TS(ul_int) },
{ RS(NUMA_PAGES_MIGRATED), TS(ul_int) },
{ RS(NUMA_PTE_UPDATES), TS(ul_int) },
{ RS(OOM_KILL), TS(ul_int) },
{ RS(PAGEOUTRUN), TS(ul_int) },
{ RS(PGACTIVATE), TS(ul_int) },
{ RS(PGALLOC_DMA), TS(ul_int) },
{ RS(PGALLOC_DMA32), TS(ul_int) },
{ RS(PGALLOC_HIGH), TS(ul_int) },
{ RS(PGALLOC_MOVABLE), TS(ul_int) },
{ RS(PGALLOC_NORMAL), TS(ul_int) },
{ RS(PGDEACTIVATE), TS(ul_int) },
{ RS(PGFAULT), TS(ul_int) },
{ RS(PGFREE), TS(ul_int) },
{ RS(PGINODESTEAL), TS(ul_int) },
{ RS(PGLAZYFREE), TS(ul_int) },
{ RS(PGLAZYFREED), TS(ul_int) },
{ RS(PGMAJFAULT), TS(ul_int) },
{ RS(PGMIGRATE_FAIL), TS(ul_int) },
{ RS(PGMIGRATE_SUCCESS), TS(ul_int) },
{ RS(PGPGIN), TS(ul_int) },
{ RS(PGPGOUT), TS(ul_int) },
{ RS(PGREFILL), TS(ul_int) },
{ RS(PGROTATED), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(PGSCAN_ANON), 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(PGSCAN_DIRECT), TS(ul_int) },
{ RS(PGSCAN_DIRECT_THROTTLE), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(PGSCAN_FILE), 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(PGSCAN_KSWAPD), TS(ul_int) },
{ RS(PGSKIP_DMA), TS(ul_int) },
{ RS(PGSKIP_DMA32), TS(ul_int) },
{ RS(PGSKIP_HIGH), TS(ul_int) },
{ RS(PGSKIP_MOVABLE), TS(ul_int) },
{ RS(PGSKIP_NORMAL), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(PGSTEAL_ANON), 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(PGSTEAL_DIRECT), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(PGSTEAL_FILE), 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(PGSTEAL_KSWAPD), TS(ul_int) },
{ RS(PSWPIN), TS(ul_int) },
{ RS(PSWPOUT), TS(ul_int) },
{ RS(SLABS_SCANNED), TS(ul_int) },
{ RS(SWAP_RA), TS(ul_int) },
{ RS(SWAP_RA_HIT), TS(ul_int) },
{ RS(THP_COLLAPSE_ALLOC), TS(ul_int) },
{ RS(THP_COLLAPSE_ALLOC_FAILED), TS(ul_int) },
{ RS(THP_DEFERRED_SPLIT_PAGE), TS(ul_int) },
{ RS(THP_FAULT_ALLOC), TS(ul_int) },
{ RS(THP_FAULT_FALLBACK), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(THP_FAULT_FALLBACK_CHARGE), 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(THP_FILE_ALLOC), TS(ul_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(THP_FILE_FALLBACK), TS(ul_int) },
{ RS(THP_FILE_FALLBACK_CHARGE), 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(THP_FILE_MAPPED), TS(ul_int) },
{ RS(THP_SPLIT_PAGE), TS(ul_int) },
{ RS(THP_SPLIT_PAGE_FAILED), TS(ul_int) },
{ RS(THP_SPLIT_PMD), TS(ul_int) },
{ RS(THP_SPLIT_PUD), TS(ul_int) },
{ RS(THP_SWPOUT), TS(ul_int) },
{ RS(THP_SWPOUT_FALLBACK), TS(ul_int) },
{ RS(THP_ZERO_PAGE_ALLOC), TS(ul_int) },
{ RS(THP_ZERO_PAGE_ALLOC_FAILED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_CLEARED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_CULLED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_MLOCKED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_MUNLOCKED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_RESCUED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_SCANNED), TS(ul_int) },
{ RS(UNEVICTABLE_PGS_STRANDED), TS(ul_int) },
{ RS(WORKINGSET_ACTIVATE), TS(ul_int) },
{ RS(WORKINGSET_NODERECLAIM), TS(ul_int) },
{ RS(WORKINGSET_NODES), TS(ul_int) },
{ RS(WORKINGSET_REFAULT), TS(ul_int) },
{ RS(WORKINGSET_RESTORE), TS(ul_int) },
{ RS(ZONE_RECLAIM_FAILED), TS(ul_int) },
{ RS(DELTA_ALLOCSTALL_DMA), TS(sl_int) },
{ RS(DELTA_ALLOCSTALL_DMA32), TS(sl_int) },
{ RS(DELTA_ALLOCSTALL_HIGH), TS(sl_int) },
{ RS(DELTA_ALLOCSTALL_MOVABLE), TS(sl_int) },
{ RS(DELTA_ALLOCSTALL_NORMAL), TS(sl_int) },
{ RS(DELTA_BALLOON_DEFLATE), TS(sl_int) },
{ RS(DELTA_BALLOON_INFLATE), TS(sl_int) },
{ RS(DELTA_BALLOON_MIGRATE), TS(sl_int) },
{ RS(DELTA_COMPACT_DAEMON_FREE_SCANNED), TS(sl_int) },
{ RS(DELTA_COMPACT_DAEMON_MIGRATE_SCANNED), TS(sl_int) },
{ RS(DELTA_COMPACT_DAEMON_WAKE), TS(sl_int) },
{ RS(DELTA_COMPACT_FAIL), TS(sl_int) },
{ RS(DELTA_COMPACT_FREE_SCANNED), TS(sl_int) },
{ RS(DELTA_COMPACT_ISOLATED), TS(sl_int) },
{ RS(DELTA_COMPACT_MIGRATE_SCANNED), TS(sl_int) },
{ RS(DELTA_COMPACT_STALL), TS(sl_int) },
{ RS(DELTA_COMPACT_SUCCESS), TS(sl_int) },
{ RS(DELTA_DROP_PAGECACHE), TS(sl_int) },
{ RS(DELTA_DROP_SLAB), TS(sl_int) },
{ RS(DELTA_HTLB_BUDDY_ALLOC_FAIL), TS(sl_int) },
{ RS(DELTA_HTLB_BUDDY_ALLOC_SUCCESS), TS(sl_int) },
{ RS(DELTA_KSWAPD_HIGH_WMARK_HIT_QUICKLY), TS(sl_int) },
{ RS(DELTA_KSWAPD_INODESTEAL), TS(sl_int) },
{ RS(DELTA_KSWAPD_LOW_WMARK_HIT_QUICKLY), TS(sl_int) },
{ RS(DELTA_NR_ACTIVE_ANON), TS(sl_int) },
{ RS(DELTA_NR_ACTIVE_FILE), TS(sl_int) },
{ RS(DELTA_NR_ANON_PAGES), TS(sl_int) },
{ RS(DELTA_NR_ANON_TRANSPARENT_HUGEPAGES), TS(sl_int) },
{ RS(DELTA_NR_BOUNCE), TS(sl_int) },
{ RS(DELTA_NR_DIRTIED), TS(sl_int) },
{ RS(DELTA_NR_DIRTY), TS(sl_int) },
{ RS(DELTA_NR_DIRTY_BACKGROUND_THRESHOLD), TS(sl_int) },
{ RS(DELTA_NR_DIRTY_THRESHOLD), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_NR_FILE_HUGEPAGES), TS(sl_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_NR_FILE_PAGES), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_NR_FILE_PMDMAPPED), TS(sl_int) },
{ RS(DELTA_NR_FOLL_PIN_ACQUIRED), TS(sl_int) },
{ RS(DELTA_NR_FOLL_PIN_RELEASED), TS(sl_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_NR_FREE_CMA), TS(sl_int) },
{ RS(DELTA_NR_FREE_PAGES), TS(sl_int) },
{ RS(DELTA_NR_INACTIVE_ANON), TS(sl_int) },
{ RS(DELTA_NR_INACTIVE_FILE), TS(sl_int) },
{ RS(DELTA_NR_ISOLATED_ANON), TS(sl_int) },
{ RS(DELTA_NR_ISOLATED_FILE), TS(sl_int) },
{ RS(DELTA_NR_KERNEL_MISC_RECLAIMABLE), TS(sl_int) },
{ RS(DELTA_NR_KERNEL_STACK), TS(sl_int) },
{ RS(DELTA_NR_MAPPED), TS(sl_int) },
{ RS(DELTA_NR_MLOCK), TS(sl_int) },
{ RS(DELTA_NR_PAGE_TABLE_PAGES), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_NR_SHADOW_CALL_STACK), TS(sl_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_NR_SHMEM), TS(sl_int) },
{ RS(DELTA_NR_SHMEM_HUGEPAGES), TS(sl_int) },
{ RS(DELTA_NR_SHMEM_PMDMAPPED), TS(sl_int) },
{ RS(DELTA_NR_SLAB_RECLAIMABLE), TS(sl_int) },
{ RS(DELTA_NR_SLAB_UNRECLAIMABLE), TS(sl_int) },
{ RS(DELTA_NR_UNEVICTABLE), TS(sl_int) },
{ RS(DELTA_NR_UNSTABLE), TS(sl_int) },
{ RS(DELTA_NR_VMSCAN_IMMEDIATE_RECLAIM), TS(sl_int) },
{ RS(DELTA_NR_VMSCAN_WRITE), TS(sl_int) },
{ RS(DELTA_NR_WRITEBACK), TS(sl_int) },
{ RS(DELTA_NR_WRITEBACK_TEMP), TS(sl_int) },
{ RS(DELTA_NR_WRITTEN), TS(sl_int) },
{ RS(DELTA_NR_ZONE_ACTIVE_ANON), TS(sl_int) },
{ RS(DELTA_NR_ZONE_ACTIVE_FILE), TS(sl_int) },
{ RS(DELTA_NR_ZONE_INACTIVE_ANON), TS(sl_int) },
{ RS(DELTA_NR_ZONE_INACTIVE_FILE), TS(sl_int) },
{ RS(DELTA_NR_ZONE_UNEVICTABLE), TS(sl_int) },
{ RS(DELTA_NR_ZONE_WRITE_PENDING), TS(sl_int) },
{ RS(DELTA_NR_ZSPAGES), TS(sl_int) },
{ RS(DELTA_NUMA_FOREIGN), TS(sl_int) },
{ RS(DELTA_NUMA_HINT_FAULTS), TS(sl_int) },
{ RS(DELTA_NUMA_HINT_FAULTS_LOCAL), TS(sl_int) },
{ RS(DELTA_NUMA_HIT), TS(sl_int) },
{ RS(DELTA_NUMA_HUGE_PTE_UPDATES), TS(sl_int) },
{ RS(DELTA_NUMA_INTERLEAVE), TS(sl_int) },
{ RS(DELTA_NUMA_LOCAL), TS(sl_int) },
{ RS(DELTA_NUMA_MISS), TS(sl_int) },
{ RS(DELTA_NUMA_OTHER), TS(sl_int) },
{ RS(DELTA_NUMA_PAGES_MIGRATED), TS(sl_int) },
{ RS(DELTA_NUMA_PTE_UPDATES), TS(sl_int) },
{ RS(DELTA_OOM_KILL), TS(sl_int) },
{ RS(DELTA_PAGEOUTRUN), TS(sl_int) },
{ RS(DELTA_PGACTIVATE), TS(sl_int) },
{ RS(DELTA_PGALLOC_DMA), TS(sl_int) },
{ RS(DELTA_PGALLOC_DMA32), TS(sl_int) },
{ RS(DELTA_PGALLOC_HIGH), TS(sl_int) },
{ RS(DELTA_PGALLOC_MOVABLE), TS(sl_int) },
{ RS(DELTA_PGALLOC_NORMAL), TS(sl_int) },
{ RS(DELTA_PGDEACTIVATE), TS(sl_int) },
{ RS(DELTA_PGFAULT), TS(sl_int) },
{ RS(DELTA_PGFREE), TS(sl_int) },
{ RS(DELTA_PGINODESTEAL), TS(sl_int) },
{ RS(DELTA_PGLAZYFREE), TS(sl_int) },
{ RS(DELTA_PGLAZYFREED), TS(sl_int) },
{ RS(DELTA_PGMAJFAULT), TS(sl_int) },
{ RS(DELTA_PGMIGRATE_FAIL), TS(sl_int) },
{ RS(DELTA_PGMIGRATE_SUCCESS), TS(sl_int) },
{ RS(DELTA_PGPGIN), TS(sl_int) },
{ RS(DELTA_PGPGOUT), TS(sl_int) },
{ RS(DELTA_PGREFILL), TS(sl_int) },
{ RS(DELTA_PGROTATED), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_PGSCAN_ANON), TS(sl_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_PGSCAN_DIRECT), TS(sl_int) },
{ RS(DELTA_PGSCAN_DIRECT_THROTTLE), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_PGSCAN_FILE), TS(sl_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_PGSCAN_KSWAPD), TS(sl_int) },
{ RS(DELTA_PGSKIP_DMA), TS(sl_int) },
{ RS(DELTA_PGSKIP_DMA32), TS(sl_int) },
{ RS(DELTA_PGSKIP_HIGH), TS(sl_int) },
{ RS(DELTA_PGSKIP_MOVABLE), TS(sl_int) },
{ RS(DELTA_PGSKIP_NORMAL), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_PGSTEAL_ANON), TS(sl_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_PGSTEAL_DIRECT), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_PGSTEAL_FILE), TS(sl_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_PGSTEAL_KSWAPD), TS(sl_int) },
{ RS(DELTA_PSWPIN), TS(sl_int) },
{ RS(DELTA_PSWPOUT), TS(sl_int) },
{ RS(DELTA_SLABS_SCANNED), TS(sl_int) },
{ RS(DELTA_SWAP_RA), TS(sl_int) },
{ RS(DELTA_SWAP_RA_HIT), TS(sl_int) },
{ RS(DELTA_THP_COLLAPSE_ALLOC), TS(sl_int) },
{ RS(DELTA_THP_COLLAPSE_ALLOC_FAILED), TS(sl_int) },
{ RS(DELTA_THP_DEFERRED_SPLIT_PAGE), TS(sl_int) },
{ RS(DELTA_THP_FAULT_ALLOC), TS(sl_int) },
{ RS(DELTA_THP_FAULT_FALLBACK), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_THP_FAULT_FALLBACK_CHARGE), TS(sl_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_THP_FILE_ALLOC), TS(sl_int) },
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
{ RS(DELTA_THP_FILE_FALLBACK), TS(sl_int) },
{ RS(DELTA_THP_FILE_FALLBACK_CHARGE), TS(sl_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_THP_FILE_MAPPED), TS(sl_int) },
{ RS(DELTA_THP_SPLIT_PAGE), TS(sl_int) },
{ RS(DELTA_THP_SPLIT_PAGE_FAILED), TS(sl_int) },
{ RS(DELTA_THP_SPLIT_PMD), TS(sl_int) },
{ RS(DELTA_THP_SPLIT_PUD), TS(sl_int) },
{ RS(DELTA_THP_SWPOUT), TS(sl_int) },
{ RS(DELTA_THP_SWPOUT_FALLBACK), TS(sl_int) },
{ RS(DELTA_THP_ZERO_PAGE_ALLOC), TS(sl_int) },
{ RS(DELTA_THP_ZERO_PAGE_ALLOC_FAILED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_CLEARED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_CULLED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_MLOCKED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_MUNLOCKED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_RESCUED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_SCANNED), TS(sl_int) },
{ RS(DELTA_UNEVICTABLE_PGS_STRANDED), TS(sl_int) },
{ RS(DELTA_WORKINGSET_ACTIVATE), TS(sl_int) },
{ RS(DELTA_WORKINGSET_NODERECLAIM), TS(sl_int) },
{ RS(DELTA_WORKINGSET_NODES), TS(sl_int) },
{ RS(DELTA_WORKINGSET_REFAULT), TS(sl_int) },
{ RS(DELTA_WORKINGSET_RESTORE), TS(sl_int) },
{ RS(DELTA_ZONE_RECLAIM_FAILED), TS(sl_int) },
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
};
/* please note,
* this enum MUST be 1 greater than the highest value of any enum */
library: eliminate one potential source of human error There's a huge toe-stubber awaiting future maintenance as reflected in that commit below which deals with the addition of new enumerators to the Item_table. Namely, whenever the table is grown, one must remember to also change that existing 'logical_end' enumerator's value. Well, not anymore! Since that MAXTABLE macro was added to the procps-private.h header we can now also exploit it so a 'logical_end' automatically tracks table size. This change also renders some code associated with the ITEMTABLE_DEBUG #define unnecessary. So it's gone too. Reference(s): . 08/2016, add new enumerators commit 09e1886c9e731f8b8c89a55d11f72f53f030b2de . 08/2020, added MAXTABLE macro commit c865b06c304e645c05eae0f5e06a1f49ea105285 . 08/2020, introduced ITEMTABLE_DEBUG commit 92d0297e1e4d5946c5b098e37c91c7e524a0eca0 Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-22 10:30:00 +05:30
enum vmstat_item VMSTAT_logical_end = MAXTABLE(Item_table);
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
#undef setNAME
library: fix upper bounds enum delimiter, <VMSTAT> api Oops, the PROCPS_VMSTAT_logical_end enum reflected the source state before all those DELTA enum's were added. [ plus add a couple of overlooked #undef directives, ] [ and whack an unneeded stacks_alloc assignment too! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
#undef RS
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
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline void vmstat_assign_results (
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
struct vmstat_stack *stack,
struct vmstat_hist *hist)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
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
struct vmstat_result *this = stack->head;
for (;;) {
enum vmstat_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 >= VMSTAT_logical_end)
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
break;
Item_table[item].setsfunc(this, hist);
++this;
}
return;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_assign_results
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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static void vmstat_extents_free_all (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info)
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
{
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
while (info->extents) {
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
struct stacks_extent *p = info->extents;
info->extents = info->extents->next;
free(p);
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
};
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_extents_free_all
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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline struct vmstat_result *vmstat_itemize_stack (
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
struct vmstat_result *p,
int depth,
enum vmstat_item *items)
{
struct vmstat_result *p_sav = p;
int i;
for (i = 0; i < depth; i++) {
p->item = items[i];
++p;
}
return p_sav;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_itemize_stack
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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline int vmstat_items_check_failed (
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
int numitems,
enum vmstat_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 vmstat_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_vmstat_select(info, VMSTAT_noop, num);
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
* ^~~~~~~~~~~~~~~~
*/
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 * VMSTAT_logical_end))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
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
for (i = 0; i < numitems; i++) {
// a vmstat_item is currently unsigned, but we'll protect our future
if (items[i] < 0)
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
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] >= VMSTAT_logical_end)
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
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
}
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
return 0;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_items_check_failed
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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int vmstat_make_hash_failed (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info)
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
{
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#define htVAL(f) e.key = STRINGIFY(f); e.data = &info->hist.new. f; \
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (!hsearch_r(e, ENTER, &ep, &info->hashtab)) return 1;
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
ENTRY e, *ep;
size_t n;
n = sizeof(struct vmstat_data) / sizeof(unsigned long);
// we'll follow the hsearch recommendation of an extra 25%
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (!hcreate_r(n + (n / 4), &info->hashtab))
return 1;
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
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(allocstall_dma)
htVAL(allocstall_dma32)
htVAL(allocstall_high)
htVAL(allocstall_movable)
htVAL(allocstall_normal)
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
htVAL(balloon_deflate)
htVAL(balloon_inflate)
htVAL(balloon_migrate)
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(compact_daemon_free_scanned)
htVAL(compact_daemon_migrate_scanned)
htVAL(compact_daemon_wake)
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
htVAL(compact_fail)
htVAL(compact_free_scanned)
htVAL(compact_isolated)
htVAL(compact_migrate_scanned)
htVAL(compact_stall)
htVAL(compact_success)
htVAL(drop_pagecache)
htVAL(drop_slab)
htVAL(htlb_buddy_alloc_fail)
htVAL(htlb_buddy_alloc_success)
htVAL(kswapd_high_wmark_hit_quickly)
htVAL(kswapd_inodesteal)
htVAL(kswapd_low_wmark_hit_quickly)
htVAL(nr_active_anon)
htVAL(nr_active_file)
htVAL(nr_anon_pages)
htVAL(nr_anon_transparent_hugepages)
htVAL(nr_bounce)
htVAL(nr_dirtied)
htVAL(nr_dirty)
htVAL(nr_dirty_background_threshold)
htVAL(nr_dirty_threshold)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(nr_file_hugepages)
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
htVAL(nr_file_pages)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(nr_file_pmdmapped)
htVAL(nr_foll_pin_acquired)
htVAL(nr_foll_pin_released)
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
htVAL(nr_free_cma)
htVAL(nr_free_pages)
htVAL(nr_inactive_anon)
htVAL(nr_inactive_file)
htVAL(nr_isolated_anon)
htVAL(nr_isolated_file)
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(nr_kernel_misc_reclaimable)
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
htVAL(nr_kernel_stack)
htVAL(nr_mapped)
htVAL(nr_mlock)
htVAL(nr_page_table_pages)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(nr_shadow_call_stack)
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
htVAL(nr_shmem)
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(nr_shmem_hugepages)
htVAL(nr_shmem_pmdmapped)
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
htVAL(nr_slab_reclaimable)
htVAL(nr_slab_unreclaimable)
htVAL(nr_unevictable)
htVAL(nr_unstable)
htVAL(nr_vmscan_immediate_reclaim)
htVAL(nr_vmscan_write)
htVAL(nr_writeback)
htVAL(nr_writeback_temp)
htVAL(nr_written)
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(nr_zone_active_anon)
htVAL(nr_zone_active_file)
htVAL(nr_zone_inactive_anon)
htVAL(nr_zone_inactive_file)
htVAL(nr_zone_unevictable)
htVAL(nr_zone_write_pending)
htVAL(nr_zspages)
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
htVAL(numa_foreign)
htVAL(numa_hint_faults)
htVAL(numa_hint_faults_local)
htVAL(numa_hit)
htVAL(numa_huge_pte_updates)
htVAL(numa_interleave)
htVAL(numa_local)
htVAL(numa_miss)
htVAL(numa_other)
htVAL(numa_pages_migrated)
htVAL(numa_pte_updates)
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(oom_kill)
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
htVAL(pageoutrun)
htVAL(pgactivate)
htVAL(pgalloc_dma)
htVAL(pgalloc_dma32)
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(pgalloc_high)
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
htVAL(pgalloc_movable)
htVAL(pgalloc_normal)
htVAL(pgdeactivate)
htVAL(pgfault)
htVAL(pgfree)
htVAL(pginodesteal)
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(pglazyfree)
htVAL(pglazyfreed)
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
htVAL(pgmajfault)
htVAL(pgmigrate_fail)
htVAL(pgmigrate_success)
htVAL(pgpgin)
htVAL(pgpgout)
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(pgrefill)
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
htVAL(pgrotated)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(pgscan_anon)
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(pgscan_direct)
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
htVAL(pgscan_direct_throttle)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(pgscan_file)
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(pgscan_kswapd)
htVAL(pgskip_dma)
htVAL(pgskip_dma32)
htVAL(pgskip_high)
htVAL(pgskip_movable)
htVAL(pgskip_normal)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(pgsteal_anon)
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(pgsteal_direct)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(pgsteal_file)
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(pgsteal_kswapd)
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
htVAL(pswpin)
htVAL(pswpout)
htVAL(slabs_scanned)
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(swap_ra)
htVAL(swap_ra_hit)
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
htVAL(thp_collapse_alloc)
htVAL(thp_collapse_alloc_failed)
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(thp_deferred_split_page)
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
htVAL(thp_fault_alloc)
htVAL(thp_fault_fallback)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(thp_fault_fallback_charge)
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(thp_file_alloc)
library: <vmstat> api, updated for current linux state Since last visited, there have been several new fields added to the /proc/vmstat file. Now, we are caught up. [ references shown below represent linux git commits ] Reference(s): . 6/2020, added 'pgscan_...' & 'pgsteal_...' commit 497a6c1b09902b22ceccc0f25ba4dd623e1ddb7d . 4/2020, added 'nr_shadow_call_stack' commit 628d06a48f57c36abdc2a024930212e654a501b7 . 4/2020, added 'thp_...fallback_charge' commit 85b9f46e8ea451633ccd60a7d8cacbfff9f34047 . 4/2020, added 'thp_file_fallback' commit dcdf11ee144133328664d90836e712d840d047d9 . 4/2020, added 'nr_foll_pin_...' commit 1970dc6f5226416957ad0cc70ab47386ed3195a6 . 9/2019, added 'nr_file_...' commit 60fbf0ab5da1c360e02b7f7d882bf1c0d8f7e32a Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-07 10:30:00 +05:30
htVAL(thp_file_fallback)
htVAL(thp_file_fallback_charge)
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(thp_file_mapped)
htVAL(thp_split_page)
htVAL(thp_split_page_failed)
htVAL(thp_split_pmd)
htVAL(thp_split_pud)
htVAL(thp_swpout)
htVAL(thp_swpout_fallback)
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
htVAL(thp_zero_page_alloc)
htVAL(thp_zero_page_alloc_failed)
htVAL(unevictable_pgs_cleared)
htVAL(unevictable_pgs_culled)
htVAL(unevictable_pgs_mlocked)
htVAL(unevictable_pgs_munlocked)
htVAL(unevictable_pgs_rescued)
htVAL(unevictable_pgs_scanned)
htVAL(unevictable_pgs_stranded)
htVAL(workingset_activate)
htVAL(workingset_nodereclaim)
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(workingset_nodes)
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
htVAL(workingset_refault)
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(workingset_restore)
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
htVAL(zone_reclaim_failed)
return 0;
#undef htVAL
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_make_hash_failed
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
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
/*
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* vmstat_read_failed():
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
*
* Read the data out of /proc/vmstat putting the information
* into the supplied info structure
*/
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int vmstat_read_failed (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
library: size two read buffers with manifest constants The meminfo & vmstat file read buffers are now defined through symbolic constants next to the symbolic names. [ recent attention to the /proc/stat buffer size led ] [ to this (hopefully) better approach to definitions ] Reference(s): commit 81f4a6acdf204c5c898fa707e285cdbd2389150e Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-06-29 10:30:00 +05:30
char buf[VMSTAT_BUFF];
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
char *head, *tail;
int size;
unsigned long *valptr;
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
// remember history from last time around
memcpy(&info->hist.old, &info->hist.new, sizeof(struct vmstat_data));
// clear out the soon to be 'current' values
memset(&info->hist.new, 0, sizeof(struct vmstat_data));
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: Cygwin doesnt have /proc/vmstat Make the vmstat_read_failed() return non-error for Cygwin as it always will error because /proc/vmstat doesn't exist. Patch from Achim of the Cygwin project. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-05-31 16:11:30 +05:30
#ifndef __CYGWIN__ /* /proc/vmstat does not exist */
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
if (-1 == info->vmstat_fd
library: normalized the 'read_failed' guys across APIs This patch will condense some logic in those functions associated with the file input operations. The changes will not, for the most part, alter any generated code. More significantly (though not very) was the change to two 'strtoul' calls. Since the returned 'endptr' value isn't exploited, when that parm is set to NULL, we can save one instruction on each side of such calls (wow). Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-22 11:30:00 +05:30
&& (-1 == (info->vmstat_fd = open(VMSTAT_FILE, O_RDONLY))))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
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
if (lseek(info->vmstat_fd, 0L, SEEK_SET) == -1)
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
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
library: make reads & unref logic a little more robust Since we are not using a higher level standard C fopen all of the read requests were made signal sensitive as that can result in a 'temporarily' failed i/o request. Also, protection against some user calling the 'unref' function on already free memory has been incorporated. This will protect us from some nasty 'Abort' surprise. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
for (;;) {
if ((size = read(info->vmstat_fd, buf, sizeof(buf)-1)) < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library: make reads & unref logic a little more robust Since we are not using a higher level standard C fopen all of the read requests were made signal sensitive as that can result in a 'temporarily' failed i/o request. Also, protection against some user calling the 'unref' function on already free memory has been incorporated. This will protect us from some nasty 'Abort' surprise. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
break;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
}
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (size == 0) {
errno = EIO;
return 1;
}
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
buf[size] = '\0';
head = buf;
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
library: some tweaks to 2 file read functions, 3rd gen Ever since their introduction, plus continuing through several evolutions, both the meminfo and vmstat 'read' functions employed a 'do while' loop for /proc access. However, that loop construct was wrong since identical tests were already done (twice!) within each loop body itself, then accompanied by its own 'break' statement. So, we will now transform them both into forever loops which will help us to emphasize such break statements. [ plus, let's return an error should nothing be read ] [ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ] Reference(s): . original meminfo introduction commit a20e88e4e72067c1138721c6e15e2d1130bc9595 . original vmstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-03 10:30:00 +05:30
for (;;) {
library: ensure thread safety for all static variables Even though we we had to abandon the master branch top multi-thread effort and even though the newlib version of a multi-threaded top provides no real benefit, that whole exercise was not wasted. Rather, it has revealed some deficiencies in our library which this addresses. If two or more threads in the same address space tried to access the same api simultaneously, there is a good chance some function-local static variables will yield some of those renowned unpredictable results. So, this patch protects them with the '__thread' storage class. Reference(s): https://www.freelists.org/post/procps/a-few-more-patches,7 Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-09-28 10:30:00 +05:30
static __thread ENTRY e; // keep coverity off our backs (e.data)
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
ENTRY *ep;
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
library: normalized the 'read_failed' guys across APIs This patch will condense some logic in those functions associated with the file input operations. The changes will not, for the most part, alter any generated code. More significantly (though not very) was the change to two 'strtoul' calls. Since the returned 'endptr' value isn't exploited, when that parm is set to NULL, we can save one instruction on each side of such calls (wow). Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-22 11:30:00 +05:30
if (!(tail = strchr(head, ' ')))
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
break;
*tail = '\0';
valptr = NULL;
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
e.key = head;
if (hsearch_r(e, FIND, &ep, &info->hashtab))
valptr = ep->data;
head = tail + 1;
if (valptr)
library: normalized the 'read_failed' guys across APIs This patch will condense some logic in those functions associated with the file input operations. The changes will not, for the most part, alter any generated code. More significantly (though not very) was the change to two 'strtoul' calls. Since the returned 'endptr' value isn't exploited, when that parm is set to NULL, we can save one instruction on each side of such calls (wow). Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-22 11:30:00 +05:30
*valptr = strtoul(head, NULL, 10);
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: normalized the 'read_failed' guys across APIs This patch will condense some logic in those functions associated with the file input operations. The changes will not, for the most part, alter any generated code. More significantly (though not very) was the change to two 'strtoul' calls. Since the returned 'endptr' value isn't exploited, when that parm is set to NULL, we can save one instruction on each side of such calls (wow). Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-02-22 11:30:00 +05:30
if (!(tail = strchr(head, '\n')))
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
break;
head = tail + 1;
library: some tweaks to 2 file read functions, 3rd gen Ever since their introduction, plus continuing through several evolutions, both the meminfo and vmstat 'read' functions employed a 'do while' loop for /proc access. However, that loop construct was wrong since identical tests were already done (twice!) within each loop body itself, then accompanied by its own 'break' statement. So, we will now transform them both into forever loops which will help us to emphasize such break statements. [ plus, let's return an error should nothing be read ] [ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ] Reference(s): . original meminfo introduction commit a20e88e4e72067c1138721c6e15e2d1130bc9595 . original vmstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-03 10:30:00 +05:30
}
library: Cygwin doesnt have /proc/vmstat Make the vmstat_read_failed() return non-error for Cygwin as it always will error because /proc/vmstat doesn't exist. Patch from Achim of the Cygwin project. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-05-31 16:11:30 +05:30
#endif /* !__CYGWIN__ */
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
return 0;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_read_failed
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
/*
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* vmstat_stacks_alloc():
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
*
* Allocate and initialize one or more stacks each of which is anchored in an
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* associated context structure.
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
*
* 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.
*/
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static struct stacks_extent *vmstat_stacks_alloc (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info,
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
int maxstacks)
{
struct stacks_extent *p_blob;
struct vmstat_stack **p_vect;
struct vmstat_stack *p_head;
size_t vect_size, head_size, list_size, blob_size;
void *v_head, *v_list;
int i;
vect_size = sizeof(void *) * maxstacks; // size of the addr vectors |
vect_size += sizeof(void *); // plus NULL addr delimiter |
head_size = sizeof(struct vmstat_stack); // size of that head struct |
list_size = sizeof(struct vmstat_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 our memory is allocated in a single blob, facilitating a later free(). |
as a minimum, it is important that the result structures themselves always be |
contiguous for every stack since they are accessed through relative position. | */
if (NULL == (p_blob = calloc(1, blob_size)))
return NULL;
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 |
for (i = 0; i < maxstacks; i++) {
p_head = (struct vmstat_stack *)v_head;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
p_head->head = vmstat_itemize_stack((struct vmstat_result *)v_list, info->numitems, info->items);
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
p_blob->stacks[i] = p_head;
v_list += list_size;
v_head += head_size;
}
p_blob->ext_numstacks = maxstacks;
return p_blob;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: vmstat_stacks_alloc
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
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
// --- standard required functions --------------------------------------------
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_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.
*
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
* Returns: < 0 on failure, 0 on success along with
* a pointer to a new context struct
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_EXPORT int procps_vmstat_new (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info **info)
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
{
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *p;
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
library: introduced 'Item_table' validation provisions The recent work on updating the <meminfo> and <vmstat> modules with some newly added linux fields reminded me (again) of a need for some mechanism guaranteeing that a header file agrees with the source file assumptions. Sadly, in the past, if a table entry was omitted or if the table and header are ordered differently, then the library would silently return the wrong results values or even potentially experience a SIGSEGV abnormal end. This patch offers a much needed development assist for ensuring that Item_table entries are synchronized with header file enumerators in terms of number plus order. It's intended solely for our use as libprocps evolves. Now, by activating ITEMTABLE_DEBUG, either directly or via ./configure CFLAGS='-DITEMTABLE_DEBUG', the number and order will be verified. It is envisioned that this feature will be used at least once prior to a release. Signed-off-by: Jim Warner <james.warner@comcast.net>
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
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
if (info == NULL || *info != NULL)
return -EINVAL;
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (!(p = calloc(1, sizeof(struct vmstat_info))))
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
return -ENOMEM;
p->refcount = 1;
p->vmstat_fd = -1;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (vmstat_make_hash_failed(p)) {
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
free(p);
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -errno;
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
}
library: add priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
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 |
library: eliminate distorted history 1st time switches Upon reflection, at the point where the 'priming read' was introduced, any possibility of history distortions was also eliminated. This was true because all of the 'old' (zeroed) data will have been replaced with 'new' data whenever a user finally calls get, select & reap. Thus, any DELTA values will automatically reflect that interval between 'new' and subsequent retrieval calls. [ diskstats didn't actually employ a 1st time switch ] [ like the others so we have changed a comment only. ] [ but that module will retain something similar used ] [ inside node_update whenever a new node is created. ] Reference(s): . priming read added to slabinfo commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 . priming read added to diskstats commit ecd64f444593a0badf6db6a27fcbc46a3888551d . priming read added to meminfo, stat, vmstat commit 1a2b62c7793f5f6865eec56a6f996e55495725bf Signed-off-by: Jim Warner <james.warner@comcast.net>
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' | */
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (vmstat_read_failed(p)) {
library: add priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 15:14:44 +05:30
procps_vmstat_unref(&p);
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -errno;
library: add priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 15:14:44 +05:30
}
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
*info = p;
return 0;
} // end: procps_vmstat_new
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
PROCPS_EXPORT int procps_vmstat_ref (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
if (info == NULL)
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
return -EINVAL;
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
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
info->refcount++;
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
return info->refcount;
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
} // end: procps_vmstat_ref
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
PROCPS_EXPORT int procps_vmstat_unref (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info **info)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
if (info == NULL || *info == NULL)
return -EINVAL;
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
(*info)->refcount--;
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
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
if ((*info)->refcount < 1) {
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
int errno_sav = errno;
library: at unref, close these cached file descriptors Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-06-02 10:30:00 +05:30
if ((*info)->vmstat_fd != -1)
close((*info)->vmstat_fd);
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
if ((*info)->extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
vmstat_extents_free_all((*info));
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
if ((*info)->items)
free((*info)->items);
hdestroy_r(&(*info)->hashtab);
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
free(*info);
*info = NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = errno_sav;
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
return 0;
}
return (*info)->refcount;
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
} // end: procps_vmstat_unref
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
// --- variable interface functions -------------------------------------------
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
PROCPS_EXPORT struct vmstat_result *procps_vmstat_get (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info,
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
enum vmstat_item item)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
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
time_t cur_secs;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
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
if (info == NULL)
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-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 >= VMSTAT_logical_end)
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
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
/* we will NOT read the vmstat file with every call - rather, we'll offer
a granularity of 1 second between reads ... */
cur_secs = time(NULL);
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
if (1 <= cur_secs - info->sav_secs) {
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (vmstat_read_failed(info))
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: refine support for multiple concurrent access Our new library's now well protected against potential problems which arise when a multi-threaded application opens more than one context within the same API at the same time. However, with a single-threaded application designed along those same lines, some problems remain. So, to avoid potential corruption of some data (which was classified as local 'static __thread') from those single-threaded designs, we'll move several variables to the info structure itself and remove the '__thread' qualifier. Now they're protected against both designs. [ we'll not be protected against some multi-threaded ] [ application that shares a single context yet calls ] [ that interface from separate threads. this is just ] [ bad application design & no different than sharing ] [ other modifiable global data between such threads! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-11-10 10:30:00 +05:30
info->sav_secs = cur_secs;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
}
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
info->get_this.item = item;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
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;
library: <VMSTAT> api, change in the 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
Item_table[item].setsfunc(&info->get_this, &info->hist);
return &info->get_this;
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
} // end: procps_vmstat_get
/* procps_vmstat_select():
*
* Harvest all the requested /proc/vmstat information then return
* it in a results stack.
*
* Returns: pointer to a vmstat_stack struct on success, NULL on error.
*/
PROCPS_EXPORT struct vmstat_stack *procps_vmstat_select (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct vmstat_info *info,
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
enum vmstat_item *items,
int numitems)
library: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
{
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
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
if (info == NULL || items == NULL)
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (vmstat_items_check_failed(numitems, items))
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
return NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
library: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
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
/* 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 vmstat_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 VMSTAT_logical_end
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
if (!(info->items = realloc(info->items, sizeof(enum vmstat_item) * (numitems + 1))))
return NULL;
memcpy(info->items, items, sizeof(enum vmstat_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] = VMSTAT_logical_end;
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
info->numitems = numitems + 1;
if (info->extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
vmstat_extents_free_all(info);
library: vmstat redesign now using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . Standard copyright boilerplate was added in .c file. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
}
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
if (!info->extents
library: accumulated miscellaneous code/comment tweaks Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-24 23:42:12 +05:30
&& (!vmstat_stacks_alloc(info, 1)))
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
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (vmstat_read_failed(info))
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
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
vmstat_assign_results(info->extents->stacks[0], &info->hist);
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
return info->extents->stacks[0];
} // end: procps_vmstat_select
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
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
library: show allowable range in relative enum warning This patch just trades the 'typestr' for the much more meaningful 'valid range' when a relative enum has been deemed invalid under that XTRA_PROCPS_DEBUG provision. [ and we'll also make one comment a bit more generic ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-13 10:30:00 +05:30
* 2) an #include of 'xtra-procps-debug.h' is used
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
*/
PROCPS_EXPORT struct vmstat_result *xtra_vmstat_get (
struct vmstat_info *info,
enum vmstat_item actual_enum,
const char *typestr,
const char *file,
int lineno)
{
struct vmstat_result *r = procps_vmstat_get(info, actual_enum);
library: ensure that all those 'GET' macros are robust When users call the native 'get' functions they have a responsibility to check that the result struct address was indeed returned. But when using those 'GET' macros there was no protection for possible NULL dereference. So this patch will add some protection for a potential failure of an underlying 'get' function. And should it occur then those 'GET' macros will just return a zero. Plus, we'll also mirror that behavior in the debugging header should the XTRA_PROCPS_DEBUG #define be active. And, we might as well add a warning when invalid items are passed to 'GET' macros, just like we do for 'VAL'. [ lastly, we added the missing opening parens/braces ] [ to 2 'GET' macros in that xtra-procps-debug.h file ] [ which went unnoticed until the qa folks caught up. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-06 21:41:11 +05:30
if (actual_enum < 0 || actual_enum >= VMSTAT_logical_end) {
fprintf(stderr, "%s line %d: invalid item = %d, type = %s\n"
, file, lineno, actual_enum, typestr);
}
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
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_vmstat_get_
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
PROCPS_EXPORT struct vmstat_result *xtra_vmstat_val (
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
int relative_enum,
const char *typestr,
const struct vmstat_stack *stack,
struct vmstat_info *info,
const char *file,
int lineno)
{
char *str;
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
int i;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
for (i = 0; stack->head[i].item < VMSTAT_logical_end; i++)
;
if (relative_enum < 0 || relative_enum >= i) {
library: show allowable range in relative enum warning This patch just trades the 'typestr' for the much more meaningful 'valid range' when a relative enum has been deemed invalid under that XTRA_PROCPS_DEBUG provision. [ and we'll also make one comment a bit more generic ] Signed-off-by: Jim Warner <james.warner@comcast.net>
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);
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
return NULL;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
}
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
str = Item_table[stack->head[relative_enum].item].type2str;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (str[0]
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
&& (strcmp(typestr, str))) {
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
}
return &stack->head[relative_enum];
library: clean up some miscellaneous compiler warnings Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-03 10:30:00 +05:30
(void)info;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
} // end: xtra_vmstat_val
Reference in New Issue Copy Permalink