emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
b3b6984bfe
procps/proc/vmstat.h

313 lines
16 KiB
C
Raw Normal View History

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
/*
* libprocps - Library to read proc filesystem
*
* Copyright (C) 1995 Martin Schulze <joey@infodrom.north.de>
* Copyright (C) 1996 Charles Blake <cblake@bbn.com>
* Copyright (C) 2003 Albert Cahalan
* Copyright (C) 2015 Craig Small <csmall@enc.com.au>
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
* Copyright (C) 2016 Jim Warner <james.warner@comcast.net>
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
*
* 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
*/
#ifndef PROC_VMSTAT_H
#define PROC_VMSTAT_H
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
#include <sys/cdefs.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
__BEGIN_DECLS
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
VMSTAT_noop, // ( never altered )
VMSTAT_extra, // ( reset to zero )
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: 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
VMSTAT_ALLOCSTALL, // ul_int
VMSTAT_BALLOON_DEFLATE, // ul_int
VMSTAT_BALLOON_INFLATE, // ul_int
VMSTAT_BALLOON_MIGRATE, // ul_int
VMSTAT_COMPACT_FAIL, // ul_int
VMSTAT_COMPACT_FREE_SCANNED, // ul_int
VMSTAT_COMPACT_ISOLATED, // ul_int
VMSTAT_COMPACT_MIGRATE_SCANNED, // ul_int
VMSTAT_COMPACT_STALL, // ul_int
VMSTAT_COMPACT_SUCCESS, // ul_int
VMSTAT_DROP_PAGECACHE, // ul_int
VMSTAT_DROP_SLAB, // ul_int
VMSTAT_HTLB_BUDDY_ALLOC_FAIL, // ul_int
VMSTAT_HTLB_BUDDY_ALLOC_SUCCESS, // ul_int
VMSTAT_KSWAPD_HIGH_WMARK_HIT_QUICKLY, // ul_int
VMSTAT_KSWAPD_INODESTEAL, // ul_int
VMSTAT_KSWAPD_LOW_WMARK_HIT_QUICKLY, // ul_int
VMSTAT_NR_ACTIVE_ANON, // ul_int
VMSTAT_NR_ACTIVE_FILE, // ul_int
VMSTAT_NR_ALLOC_BATCH, // ul_int
VMSTAT_NR_ANON_PAGES, // ul_int
VMSTAT_NR_ANON_TRANSPARENT_HUGEPAGES, // ul_int
VMSTAT_NR_BOUNCE, // ul_int
VMSTAT_NR_DIRTIED, // ul_int
VMSTAT_NR_DIRTY, // ul_int
VMSTAT_NR_DIRTY_BACKGROUND_THRESHOLD, // ul_int
VMSTAT_NR_DIRTY_THRESHOLD, // ul_int
VMSTAT_NR_FILE_PAGES, // ul_int
VMSTAT_NR_FREE_CMA, // ul_int
VMSTAT_NR_FREE_PAGES, // ul_int
VMSTAT_NR_INACTIVE_ANON, // ul_int
VMSTAT_NR_INACTIVE_FILE, // ul_int
VMSTAT_NR_ISOLATED_ANON, // ul_int
VMSTAT_NR_ISOLATED_FILE, // ul_int
VMSTAT_NR_KERNEL_STACK, // ul_int
VMSTAT_NR_MAPPED, // ul_int
VMSTAT_NR_MLOCK, // ul_int
VMSTAT_NR_PAGES_SCANNED, // ul_int
VMSTAT_NR_PAGE_TABLE_PAGES, // ul_int
VMSTAT_NR_SHMEM, // ul_int
VMSTAT_NR_SLAB_RECLAIMABLE, // ul_int
VMSTAT_NR_SLAB_UNRECLAIMABLE, // ul_int
VMSTAT_NR_UNEVICTABLE, // ul_int
VMSTAT_NR_UNSTABLE, // ul_int
VMSTAT_NR_VMSCAN_IMMEDIATE_RECLAIM, // ul_int
VMSTAT_NR_VMSCAN_WRITE, // ul_int
VMSTAT_NR_WRITEBACK, // ul_int
VMSTAT_NR_WRITEBACK_TEMP, // ul_int
VMSTAT_NR_WRITTEN, // ul_int
VMSTAT_NUMA_FOREIGN, // ul_int
VMSTAT_NUMA_HINT_FAULTS, // ul_int
VMSTAT_NUMA_HINT_FAULTS_LOCAL, // ul_int
VMSTAT_NUMA_HIT, // ul_int
VMSTAT_NUMA_HUGE_PTE_UPDATES, // ul_int
VMSTAT_NUMA_INTERLEAVE, // ul_int
VMSTAT_NUMA_LOCAL, // ul_int
VMSTAT_NUMA_MISS, // ul_int
VMSTAT_NUMA_OTHER, // ul_int
VMSTAT_NUMA_PAGES_MIGRATED, // ul_int
VMSTAT_NUMA_PTE_UPDATES, // ul_int
VMSTAT_PAGEOUTRUN, // ul_int
VMSTAT_PGACTIVATE, // ul_int
VMSTAT_PGALLOC_DMA, // ul_int
VMSTAT_PGALLOC_DMA32, // ul_int
VMSTAT_PGALLOC_MOVABLE, // ul_int
VMSTAT_PGALLOC_NORMAL, // ul_int
VMSTAT_PGDEACTIVATE, // ul_int
VMSTAT_PGFAULT, // ul_int
VMSTAT_PGFREE, // ul_int
VMSTAT_PGINODESTEAL, // ul_int
VMSTAT_PGMAJFAULT, // ul_int
VMSTAT_PGMIGRATE_FAIL, // ul_int
VMSTAT_PGMIGRATE_SUCCESS, // ul_int
VMSTAT_PGPGIN, // ul_int
VMSTAT_PGPGOUT, // ul_int
VMSTAT_PGREFILL_DMA, // ul_int
VMSTAT_PGREFILL_DMA32, // ul_int
VMSTAT_PGREFILL_MOVABLE, // ul_int
VMSTAT_PGREFILL_NORMAL, // ul_int
VMSTAT_PGROTATED, // ul_int
VMSTAT_PGSCAN_DIRECT_DMA, // ul_int
VMSTAT_PGSCAN_DIRECT_DMA32, // ul_int
VMSTAT_PGSCAN_DIRECT_MOVABLE, // ul_int
VMSTAT_PGSCAN_DIRECT_NORMAL, // ul_int
VMSTAT_PGSCAN_DIRECT_THROTTLE, // ul_int
VMSTAT_PGSCAN_KSWAPD_DMA, // ul_int
VMSTAT_PGSCAN_KSWAPD_DMA32, // ul_int
VMSTAT_PGSCAN_KSWAPD_MOVEABLE, // ul_int
VMSTAT_PGSCAN_KSWAPD_NORMAL, // ul_int
VMSTAT_PGSTEAL_DIRECT_DMA, // ul_int
VMSTAT_PGSTEAL_DIRECT_DMA32, // ul_int
VMSTAT_PGSTEAL_DIRECT_MOVABLE, // ul_int
VMSTAT_PGSTEAL_DIRECT_NORMAL, // ul_int
VMSTAT_PGSTEAL_KSWAPD_DMA, // ul_int
VMSTAT_PGSTEAL_KSWAPD_DMA32, // ul_int
VMSTAT_PGSTEAL_KSWAPD_MOVABLE, // ul_int
VMSTAT_PGSTEAL_KSWAPD_NORMAL, // ul_int
VMSTAT_PSWPIN, // ul_int
VMSTAT_PSWPOUT, // ul_int
VMSTAT_SLABS_SCANNED, // ul_int
VMSTAT_THP_COLLAPSE_ALLOC, // ul_int
VMSTAT_THP_COLLAPSE_ALLOC_FAILED, // ul_int
VMSTAT_THP_FAULT_ALLOC, // ul_int
VMSTAT_THP_FAULT_FALLBACK, // ul_int
VMSTAT_THP_SPLIT, // ul_int
VMSTAT_THP_ZERO_PAGE_ALLOC, // ul_int
VMSTAT_THP_ZERO_PAGE_ALLOC_FAILED, // ul_int
VMSTAT_UNEVICTABLE_PGS_CLEARED, // ul_int
VMSTAT_UNEVICTABLE_PGS_CULLED, // ul_int
VMSTAT_UNEVICTABLE_PGS_MLOCKED, // ul_int
VMSTAT_UNEVICTABLE_PGS_MUNLOCKED, // ul_int
VMSTAT_UNEVICTABLE_PGS_RESCUED, // ul_int
VMSTAT_UNEVICTABLE_PGS_SCANNED, // ul_int
VMSTAT_UNEVICTABLE_PGS_STRANDED, // ul_int
VMSTAT_WORKINGSET_ACTIVATE, // ul_int
VMSTAT_WORKINGSET_NODERECLAIM, // ul_int
VMSTAT_WORKINGSET_REFAULT, // ul_int
VMSTAT_ZONE_RECLAIM_FAILED, // ul_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
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
VMSTAT_DELTA_ALLOCSTALL, // sl_int
VMSTAT_DELTA_BALLOON_DEFLATE, // sl_int
VMSTAT_DELTA_BALLOON_INFLATE, // sl_int
VMSTAT_DELTA_BALLOON_MIGRATE, // sl_int
VMSTAT_DELTA_COMPACT_FAIL, // sl_int
VMSTAT_DELTA_COMPACT_FREE_SCANNED, // sl_int
VMSTAT_DELTA_COMPACT_ISOLATED, // sl_int
VMSTAT_DELTA_COMPACT_MIGRATE_SCANNED, // sl_int
VMSTAT_DELTA_COMPACT_STALL, // sl_int
VMSTAT_DELTA_COMPACT_SUCCESS, // sl_int
VMSTAT_DELTA_DROP_PAGECACHE, // sl_int
VMSTAT_DELTA_DROP_SLAB, // sl_int
VMSTAT_DELTA_HTLB_BUDDY_ALLOC_FAIL, // sl_int
VMSTAT_DELTA_HTLB_BUDDY_ALLOC_SUCCESS, // sl_int
VMSTAT_DELTA_KSWAPD_HIGH_WMARK_HIT_QUICKLY, // sl_int
VMSTAT_DELTA_KSWAPD_INODESTEAL, // sl_int
VMSTAT_DELTA_KSWAPD_LOW_WMARK_HIT_QUICKLY, // sl_int
VMSTAT_DELTA_NR_ACTIVE_ANON, // sl_int
VMSTAT_DELTA_NR_ACTIVE_FILE, // sl_int
VMSTAT_DELTA_NR_ALLOC_BATCH, // sl_int
VMSTAT_DELTA_NR_ANON_PAGES, // sl_int
VMSTAT_DELTA_NR_ANON_TRANSPARENT_HUGEPAGES, // sl_int
VMSTAT_DELTA_NR_BOUNCE, // sl_int
VMSTAT_DELTA_NR_DIRTIED, // sl_int
VMSTAT_DELTA_NR_DIRTY, // sl_int
VMSTAT_DELTA_NR_DIRTY_BACKGROUND_THRESHOLD, // sl_int
VMSTAT_DELTA_NR_DIRTY_THRESHOLD, // sl_int
VMSTAT_DELTA_NR_FILE_PAGES, // sl_int
VMSTAT_DELTA_NR_FREE_CMA, // sl_int
VMSTAT_DELTA_NR_FREE_PAGES, // sl_int
VMSTAT_DELTA_NR_INACTIVE_ANON, // sl_int
VMSTAT_DELTA_NR_INACTIVE_FILE, // sl_int
VMSTAT_DELTA_NR_ISOLATED_ANON, // sl_int
VMSTAT_DELTA_NR_ISOLATED_FILE, // sl_int
VMSTAT_DELTA_NR_KERNEL_STACK, // sl_int
VMSTAT_DELTA_NR_MAPPED, // sl_int
VMSTAT_DELTA_NR_MLOCK, // sl_int
VMSTAT_DELTA_NR_PAGES_SCANNED, // sl_int
VMSTAT_DELTA_NR_PAGE_TABLE_PAGES, // sl_int
VMSTAT_DELTA_NR_SHMEM, // sl_int
VMSTAT_DELTA_NR_SLAB_RECLAIMABLE, // sl_int
VMSTAT_DELTA_NR_SLAB_UNRECLAIMABLE, // sl_int
VMSTAT_DELTA_NR_UNEVICTABLE, // sl_int
VMSTAT_DELTA_NR_UNSTABLE, // sl_int
VMSTAT_DELTA_NR_VMSCAN_IMMEDIATE_RECLAIM, // sl_int
VMSTAT_DELTA_NR_VMSCAN_WRITE, // sl_int
VMSTAT_DELTA_NR_WRITEBACK, // sl_int
VMSTAT_DELTA_NR_WRITEBACK_TEMP, // sl_int
VMSTAT_DELTA_NR_WRITTEN, // sl_int
VMSTAT_DELTA_NUMA_FOREIGN, // sl_int
VMSTAT_DELTA_NUMA_HINT_FAULTS, // sl_int
VMSTAT_DELTA_NUMA_HINT_FAULTS_LOCAL, // sl_int
VMSTAT_DELTA_NUMA_HIT, // sl_int
VMSTAT_DELTA_NUMA_HUGE_PTE_UPDATES, // sl_int
VMSTAT_DELTA_NUMA_INTERLEAVE, // sl_int
VMSTAT_DELTA_NUMA_LOCAL, // sl_int
VMSTAT_DELTA_NUMA_MISS, // sl_int
VMSTAT_DELTA_NUMA_OTHER, // sl_int
VMSTAT_DELTA_NUMA_PAGES_MIGRATED, // sl_int
VMSTAT_DELTA_NUMA_PTE_UPDATES, // sl_int
VMSTAT_DELTA_PAGEOUTRUN, // sl_int
VMSTAT_DELTA_PGACTIVATE, // sl_int
VMSTAT_DELTA_PGALLOC_DMA, // sl_int
VMSTAT_DELTA_PGALLOC_DMA32, // sl_int
VMSTAT_DELTA_PGALLOC_MOVABLE, // sl_int
VMSTAT_DELTA_PGALLOC_NORMAL, // sl_int
VMSTAT_DELTA_PGDEACTIVATE, // sl_int
VMSTAT_DELTA_PGFAULT, // sl_int
VMSTAT_DELTA_PGFREE, // sl_int
VMSTAT_DELTA_PGINODESTEAL, // sl_int
VMSTAT_DELTA_PGMAJFAULT, // sl_int
VMSTAT_DELTA_PGMIGRATE_FAIL, // sl_int
VMSTAT_DELTA_PGMIGRATE_SUCCESS, // sl_int
VMSTAT_DELTA_PGPGIN, // sl_int
VMSTAT_DELTA_PGPGOUT, // sl_int
VMSTAT_DELTA_PGREFILL_DMA, // sl_int
VMSTAT_DELTA_PGREFILL_DMA32, // sl_int
VMSTAT_DELTA_PGREFILL_MOVABLE, // sl_int
VMSTAT_DELTA_PGREFILL_NORMAL, // sl_int
VMSTAT_DELTA_PGROTATED, // sl_int
VMSTAT_DELTA_PGSCAN_DIRECT_DMA, // sl_int
VMSTAT_DELTA_PGSCAN_DIRECT_DMA32, // sl_int
VMSTAT_DELTA_PGSCAN_DIRECT_MOVABLE, // sl_int
VMSTAT_DELTA_PGSCAN_DIRECT_NORMAL, // sl_int
VMSTAT_DELTA_PGSCAN_DIRECT_THROTTLE, // sl_int
VMSTAT_DELTA_PGSCAN_KSWAPD_DMA, // sl_int
VMSTAT_DELTA_PGSCAN_KSWAPD_DMA32, // sl_int
VMSTAT_DELTA_PGSCAN_KSWAPD_MOVEABLE, // sl_int
VMSTAT_DELTA_PGSCAN_KSWAPD_NORMAL, // sl_int
VMSTAT_DELTA_PGSTEAL_DIRECT_DMA, // sl_int
VMSTAT_DELTA_PGSTEAL_DIRECT_DMA32, // sl_int
VMSTAT_DELTA_PGSTEAL_DIRECT_MOVABLE, // sl_int
VMSTAT_DELTA_PGSTEAL_DIRECT_NORMAL, // sl_int
VMSTAT_DELTA_PGSTEAL_KSWAPD_DMA, // sl_int
VMSTAT_DELTA_PGSTEAL_KSWAPD_DMA32, // sl_int
VMSTAT_DELTA_PGSTEAL_KSWAPD_MOVABLE, // sl_int
VMSTAT_DELTA_PGSTEAL_KSWAPD_NORMAL, // sl_int
VMSTAT_DELTA_PSWPIN, // sl_int
VMSTAT_DELTA_PSWPOUT, // sl_int
VMSTAT_DELTA_SLABS_SCANNED, // sl_int
VMSTAT_DELTA_THP_COLLAPSE_ALLOC, // sl_int
VMSTAT_DELTA_THP_COLLAPSE_ALLOC_FAILED, // sl_int
VMSTAT_DELTA_THP_FAULT_ALLOC, // sl_int
VMSTAT_DELTA_THP_FAULT_FALLBACK, // sl_int
VMSTAT_DELTA_THP_SPLIT, // sl_int
VMSTAT_DELTA_THP_ZERO_PAGE_ALLOC, // sl_int
VMSTAT_DELTA_THP_ZERO_PAGE_ALLOC_FAILED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_CLEARED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_CULLED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_MLOCKED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_MUNLOCKED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_RESCUED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_SCANNED, // sl_int
VMSTAT_DELTA_UNEVICTABLE_PGS_STRANDED, // sl_int
VMSTAT_DELTA_WORKINGSET_ACTIVATE, // sl_int
VMSTAT_DELTA_WORKINGSET_NODERECLAIM, // sl_int
VMSTAT_DELTA_WORKINGSET_REFAULT, // sl_int
VMSTAT_DELTA_ZONE_RECLAIM_FAILED // sl_int
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: 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: 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 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
struct vmstat_result {
enum vmstat_item item;
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
union {
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
signed long sl_int;
unsigned long ul_int;
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
} result;
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
struct vmstat_stack {
struct vmstat_result *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
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
#define VMSTAT_GET( info, actual_enum, type ) ( { \
struct vmstat_result *r = procps_vmstat_get( info, actual_enum ); \
r ? r->result . type : 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
library: expand VAL macros to include the context parm This patch will set the stage for validating the types referenced in the result union. For now, the parameter representing that 'info' structure will remain unused. [ and while we're at it, let us correct a faulty GET ] [ macro in the diskstats header. that puppy missed a ] [ parm which ain't so good if that guy is ever used! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#define VMSTAT_VAL( relative_enum, type, stack, 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
stack -> head [ relative_enum ] . result . type
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;
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
int procps_vmstat_new (struct vmstat_info **info);
int procps_vmstat_ref (struct vmstat_info *info);
int procps_vmstat_unref (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
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 *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: 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
enum vmstat_item item);
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 *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: 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
__END_DECLS
#endif
Reference in New Issue Copy Permalink