2015-06-21 13:52:28 +05:30
|
|
|
/*
|
2016-05-11 22:30:00 +05:30
|
|
|
* libprocps - Library to read proc filesystem
|
2015-06-21 13:52:28 +05:30
|
|
|
*
|
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with this library; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
|
*/
|
2015-07-21 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <errno.h>
|
2015-07-21 10:30:00 +05:30
|
|
|
#include <fcntl.h>
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
#include <search.h>
|
2016-05-11 22:30:00 +05:30
|
|
|
#include <stdio.h>
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
2016-05-11 22:30:00 +05:30
|
|
|
#include <time.h>
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <unistd.h>
|
2015-07-21 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <sys/stat.h>
|
2015-07-21 10:30:00 +05:30
|
|
|
#include <sys/types.h>
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
#include <proc/procps-private.h>
|
2015-06-20 18:38:47 +05:30
|
|
|
#include <proc/meminfo.h>
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
|
|
|
|
#define MEMINFO_FILE "/proc/meminfo"
|
|
|
|
|
|
2016-06-09 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
struct meminfo_data {
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Active;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
unsigned long Active_anon; // as: Active(anon):
|
|
|
|
|
unsigned long Active_file; // as: Active(file):
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long AnonHugePages;
|
|
|
|
|
unsigned long AnonPages;
|
|
|
|
|
unsigned long Bounce;
|
|
|
|
|
unsigned long Buffers;
|
|
|
|
|
unsigned long Cached;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
unsigned long CmaFree; // man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long CmaTotal; // man 5 proc: 'to be documented'
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long CommitLimit;
|
|
|
|
|
unsigned long Committed_AS;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
unsigned long DirectMap1G; // man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long DirectMap2M; // man 5 proc: 'to be documented'
|
|
|
|
|
unsigned long DirectMap4k; // man 5 proc: 'to be documented'
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long Dirty;
|
|
|
|
|
unsigned long HardwareCorrupted;
|
|
|
|
|
unsigned long HighFree;
|
|
|
|
|
unsigned long HighTotal;
|
|
|
|
|
unsigned long HugePages_Free;
|
|
|
|
|
unsigned long HugePages_Rsvd;
|
|
|
|
|
unsigned long HugePages_Surp;
|
|
|
|
|
unsigned long HugePages_Total;
|
|
|
|
|
unsigned long Hugepagesize;
|
|
|
|
|
unsigned long Inactive;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
unsigned long Inactive_anon; // as: Inactive(anon):
|
|
|
|
|
unsigned long Inactive_file; // as: Inactive(file):
|
2016-05-11 22:30:00 +05:30
|
|
|
unsigned long KernelStack;
|
|
|
|
|
unsigned long LowFree;
|
|
|
|
|
unsigned long LowTotal;
|
|
|
|
|
unsigned long Mapped;
|
|
|
|
|
unsigned long MemAvailable;
|
|
|
|
|
unsigned long MemFree;
|
|
|
|
|
unsigned long MemTotal;
|
|
|
|
|
unsigned long Mlocked;
|
|
|
|
|
unsigned long NFS_Unstable;
|
|
|
|
|
unsigned long PageTables;
|
|
|
|
|
unsigned long SReclaimable;
|
|
|
|
|
unsigned long SUnreclaim;
|
|
|
|
|
unsigned long Shmem;
|
|
|
|
|
unsigned long Slab;
|
|
|
|
|
unsigned long SwapCached;
|
|
|
|
|
unsigned long SwapFree;
|
|
|
|
|
unsigned long SwapTotal;
|
|
|
|
|
unsigned long Unevictable;
|
|
|
|
|
unsigned long VmallocChunk;
|
|
|
|
|
unsigned long VmallocTotal;
|
|
|
|
|
unsigned long VmallocUsed;
|
|
|
|
|
unsigned long Writeback;
|
|
|
|
|
unsigned long WritebackTmp;
|
|
|
|
|
|
|
|
|
|
unsigned long derived_mem_hi_used;
|
|
|
|
|
unsigned long derived_mem_lo_used;
|
|
|
|
|
unsigned long derived_mem_used;
|
|
|
|
|
unsigned long derived_swap_used;
|
|
|
|
|
};
|
|
|
|
|
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
struct mem_hist {
|
2016-05-11 22:30:00 +05:30
|
|
|
struct meminfo_data new;
|
|
|
|
|
struct meminfo_data old;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct stacks_extent {
|
|
|
|
|
int ext_numstacks;
|
|
|
|
|
struct stacks_extent *next;
|
|
|
|
|
struct meminfo_stack **stacks;
|
2015-06-20 18:38:47 +05:30
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct procps_meminfo {
|
|
|
|
|
int refcount;
|
|
|
|
|
int meminfo_fd;
|
2016-05-11 22:30:00 +05:30
|
|
|
int meminfo_was_read;
|
|
|
|
|
int dirty_stacks;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
struct mem_hist hist;
|
2016-05-11 22:30:00 +05:30
|
|
|
int numitems;
|
|
|
|
|
enum meminfo_item *items;
|
|
|
|
|
struct stacks_extent *extents;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
struct hsearch_data hashtab;
|
2016-06-18 10:30:00 +05:30
|
|
|
struct meminfo_result get_this;
|
2015-07-11 10:30:00 +05:30
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
#define setNAME(e) set_results_ ## e
|
|
|
|
|
#define setDECL(e) static void setNAME(e) \
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
(struct meminfo_result *R, struct mem_hist *H)
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
// regular assignment
|
|
|
|
|
#define MEM_set(e,t,x) setDECL(e) { R->result. t = H->new . x; }
|
|
|
|
|
// delta assignment
|
2016-05-12 03:47:17 +05:30
|
|
|
#define HST_set(e,t,x) setDECL(e) { R->result. t = ( H->new . x - H->old. x ); }
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
setDECL(noop) { (void)R; (void)H; }
|
|
|
|
|
setDECL(extra) { (void)R; (void)H; }
|
|
|
|
|
|
|
|
|
|
MEM_set(MEM_ACTIVE, ul_int, Active)
|
|
|
|
|
MEM_set(MEM_ACTIVE_ANON, ul_int, Active_anon)
|
|
|
|
|
MEM_set(MEM_ACTIVE_FILE, ul_int, Active_file)
|
|
|
|
|
MEM_set(MEM_ANON, ul_int, AnonPages)
|
|
|
|
|
MEM_set(MEM_AVAILABLE, ul_int, MemAvailable)
|
|
|
|
|
MEM_set(MEM_BOUNCE, ul_int, Bounce)
|
|
|
|
|
MEM_set(MEM_BUFFERS, ul_int, Buffers)
|
|
|
|
|
MEM_set(MEM_CACHED, ul_int, Cached)
|
|
|
|
|
MEM_set(MEM_COMMIT_LIMIT, ul_int, CommitLimit)
|
|
|
|
|
MEM_set(MEM_COMMITTED_AS, ul_int, Committed_AS)
|
|
|
|
|
MEM_set(MEM_HARD_CORRUPTED, ul_int, HardwareCorrupted)
|
|
|
|
|
MEM_set(MEM_DIRTY, ul_int, Dirty)
|
|
|
|
|
MEM_set(MEM_FREE, ul_int, MemFree)
|
|
|
|
|
MEM_set(MEM_HUGE_ANON, ul_int, AnonHugePages)
|
|
|
|
|
MEM_set(MEM_HUGE_FREE, ul_int, HugePages_Free)
|
|
|
|
|
MEM_set(MEM_HUGE_RSVD, ul_int, HugePages_Rsvd)
|
|
|
|
|
MEM_set(MEM_HUGE_SIZE, ul_int, Hugepagesize)
|
|
|
|
|
MEM_set(MEM_HUGE_SURPLUS, ul_int, HugePages_Surp)
|
|
|
|
|
MEM_set(MEM_HUGE_TOTAL, ul_int, HugePages_Total)
|
|
|
|
|
MEM_set(MEM_INACTIVE, ul_int, Inactive)
|
|
|
|
|
MEM_set(MEM_INACTIVE_ANON, ul_int, Inactive_anon)
|
|
|
|
|
MEM_set(MEM_INACTIVE_FILE, ul_int, Inactive_file)
|
|
|
|
|
MEM_set(MEM_KERNEL_STACK, ul_int, KernelStack)
|
|
|
|
|
MEM_set(MEM_LOCKED, ul_int, Mlocked)
|
|
|
|
|
MEM_set(MEM_MAPPED, ul_int, Mapped)
|
|
|
|
|
MEM_set(MEM_NFS_UNSTABLE, ul_int, NFS_Unstable)
|
|
|
|
|
MEM_set(MEM_PAGE_TABLES, ul_int, PageTables)
|
|
|
|
|
MEM_set(MEM_SHARED, ul_int, Shmem)
|
|
|
|
|
MEM_set(MEM_SLAB, ul_int, Slab)
|
|
|
|
|
MEM_set(MEM_SLAB_RECLAIM, ul_int, SReclaimable)
|
|
|
|
|
MEM_set(MEM_SLAB_UNRECLAIM, ul_int, SUnreclaim)
|
|
|
|
|
MEM_set(MEM_TOTAL, ul_int, MemTotal)
|
|
|
|
|
MEM_set(MEM_UNEVICTABLE, ul_int, Unevictable)
|
|
|
|
|
MEM_set(MEM_USED, ul_int, derived_mem_used)
|
|
|
|
|
MEM_set(MEM_VM_ALLOC_CHUNK, ul_int, VmallocChunk)
|
2016-05-12 10:30:00 +05:30
|
|
|
MEM_set(MEM_VM_ALLOC_TOTAL, ul_int, VmallocTotal)
|
2016-05-11 22:30:00 +05:30
|
|
|
MEM_set(MEM_VM_ALLOC_USED, ul_int, VmallocUsed)
|
|
|
|
|
MEM_set(MEM_WRITEBACK, ul_int, Writeback)
|
|
|
|
|
MEM_set(MEM_WRITEBACK_TMP, ul_int, WritebackTmp)
|
|
|
|
|
|
|
|
|
|
HST_set(DELTA_ACTIVE, s_int, Active)
|
|
|
|
|
HST_set(DELTA_ACTIVE_ANON, s_int, Active_anon)
|
|
|
|
|
HST_set(DELTA_ACTIVE_FILE, s_int, Active_file)
|
|
|
|
|
HST_set(DELTA_ANON, s_int, AnonPages)
|
|
|
|
|
HST_set(DELTA_AVAILABLE, s_int, MemAvailable)
|
|
|
|
|
HST_set(DELTA_BOUNCE, s_int, Bounce)
|
|
|
|
|
HST_set(DELTA_BUFFERS, s_int, Buffers)
|
|
|
|
|
HST_set(DELTA_CACHED, s_int, Cached)
|
|
|
|
|
HST_set(DELTA_COMMIT_LIMIT, s_int, CommitLimit)
|
|
|
|
|
HST_set(DELTA_COMMITTED_AS, s_int, Committed_AS)
|
|
|
|
|
HST_set(DELTA_HARD_CORRUPTED, s_int, HardwareCorrupted)
|
|
|
|
|
HST_set(DELTA_DIRTY, s_int, Dirty)
|
|
|
|
|
HST_set(DELTA_FREE, s_int, MemFree)
|
|
|
|
|
HST_set(DELTA_HUGE_ANON, s_int, AnonHugePages)
|
|
|
|
|
HST_set(DELTA_HUGE_FREE, s_int, HugePages_Free)
|
|
|
|
|
HST_set(DELTA_HUGE_RSVD, s_int, HugePages_Rsvd)
|
|
|
|
|
HST_set(DELTA_HUGE_SIZE, s_int, Hugepagesize)
|
|
|
|
|
HST_set(DELTA_HUGE_SURPLUS, s_int, HugePages_Surp)
|
|
|
|
|
HST_set(DELTA_HUGE_TOTAL, s_int, HugePages_Total)
|
|
|
|
|
HST_set(DELTA_INACTIVE, s_int, Inactive)
|
|
|
|
|
HST_set(DELTA_INACTIVE_ANON, s_int, Inactive_anon)
|
|
|
|
|
HST_set(DELTA_INACTIVE_FILE, s_int, Inactive_file)
|
|
|
|
|
HST_set(DELTA_KERNEL_STACK, s_int, KernelStack)
|
|
|
|
|
HST_set(DELTA_LOCKED, s_int, Mlocked)
|
|
|
|
|
HST_set(DELTA_MAPPED, s_int, Mapped)
|
|
|
|
|
HST_set(DELTA_NFS_UNSTABLE, s_int, NFS_Unstable)
|
|
|
|
|
HST_set(DELTA_PAGE_TABLES, s_int, PageTables)
|
|
|
|
|
HST_set(DELTA_SHARED, s_int, Shmem)
|
|
|
|
|
HST_set(DELTA_SLAB, s_int, Slab)
|
|
|
|
|
HST_set(DELTA_SLAB_RECLAIM, s_int, SReclaimable)
|
|
|
|
|
HST_set(DELTA_SLAB_UNRECLAIM, s_int, SUnreclaim)
|
|
|
|
|
HST_set(DELTA_TOTAL, s_int, MemTotal)
|
|
|
|
|
HST_set(DELTA_UNEVICTABLE, s_int, Unevictable)
|
|
|
|
|
HST_set(DELTA_USED, s_int, derived_mem_used)
|
|
|
|
|
HST_set(DELTA_VM_ALLOC_CHUNK, s_int, VmallocChunk)
|
2016-05-12 10:30:00 +05:30
|
|
|
HST_set(DELTA_VM_ALLOC_TOTAL, s_int, VmallocTotal)
|
2016-05-11 22:30:00 +05:30
|
|
|
HST_set(DELTA_VM_ALLOC_USED, s_int, VmallocUsed)
|
|
|
|
|
HST_set(DELTA_WRITEBACK, s_int, Writeback)
|
|
|
|
|
HST_set(DELTA_WRITEBACK_TMP, s_int, WritebackTmp)
|
|
|
|
|
|
|
|
|
|
MEM_set(MEMHI_FREE, ul_int, HighFree)
|
|
|
|
|
MEM_set(MEMHI_TOTAL, ul_int, HighTotal)
|
|
|
|
|
MEM_set(MEMHI_USED, ul_int, derived_mem_hi_used)
|
|
|
|
|
|
|
|
|
|
MEM_set(MEMLO_FREE, ul_int, LowFree)
|
|
|
|
|
MEM_set(MEMLO_TOTAL, ul_int, LowTotal)
|
|
|
|
|
MEM_set(MEMLO_USED, ul_int, derived_mem_lo_used)
|
|
|
|
|
|
|
|
|
|
MEM_set(SWAP_CACHED, ul_int, SwapCached)
|
|
|
|
|
MEM_set(SWAP_FREE, ul_int, SwapFree)
|
|
|
|
|
MEM_set(SWAP_TOTAL, ul_int, SwapTotal)
|
|
|
|
|
MEM_set(SWAP_USED, ul_int, derived_swap_used)
|
|
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
#undef setDECL
|
|
|
|
|
#undef MEM_set
|
|
|
|
|
#undef HST_set
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
// ___ Controlling Table ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
typedef void (*SET_t)(struct meminfo_result *, struct mem_hist *);
|
2016-05-11 22:30:00 +05:30
|
|
|
#define RS(e) (SET_t)setNAME(e)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Need it be said?
|
|
|
|
|
* This table must be kept in the exact same order as
|
|
|
|
|
* those 'enum meminfo_item' guys ! */
|
|
|
|
|
static struct {
|
|
|
|
|
SET_t setsfunc; // the actual result setting routine
|
|
|
|
|
} Item_table[] = {
|
2016-06-18 10:30:00 +05:30
|
|
|
/* setsfunc
|
|
|
|
|
-------------------------- */
|
|
|
|
|
{ RS(noop) },
|
|
|
|
|
{ RS(extra) },
|
|
|
|
|
|
|
|
|
|
{ RS(MEM_ACTIVE) },
|
|
|
|
|
{ RS(MEM_ACTIVE_ANON) },
|
|
|
|
|
{ RS(MEM_ACTIVE_FILE) },
|
|
|
|
|
{ RS(MEM_ANON) },
|
|
|
|
|
{ RS(MEM_AVAILABLE) },
|
|
|
|
|
{ RS(MEM_BOUNCE) },
|
|
|
|
|
{ RS(MEM_BUFFERS) },
|
|
|
|
|
{ RS(MEM_CACHED) },
|
|
|
|
|
{ RS(MEM_COMMIT_LIMIT) },
|
|
|
|
|
{ RS(MEM_COMMITTED_AS) },
|
|
|
|
|
{ RS(MEM_HARD_CORRUPTED) },
|
|
|
|
|
{ RS(MEM_DIRTY) },
|
|
|
|
|
{ RS(MEM_FREE) },
|
|
|
|
|
{ RS(MEM_HUGE_ANON) },
|
|
|
|
|
{ RS(MEM_HUGE_FREE) },
|
|
|
|
|
{ RS(MEM_HUGE_RSVD) },
|
|
|
|
|
{ RS(MEM_HUGE_SIZE) },
|
|
|
|
|
{ RS(MEM_HUGE_SURPLUS) },
|
|
|
|
|
{ RS(MEM_HUGE_TOTAL) },
|
|
|
|
|
{ RS(MEM_INACTIVE) },
|
|
|
|
|
{ RS(MEM_INACTIVE_ANON) },
|
|
|
|
|
{ RS(MEM_INACTIVE_FILE) },
|
|
|
|
|
{ RS(MEM_KERNEL_STACK) },
|
|
|
|
|
{ RS(MEM_LOCKED) },
|
|
|
|
|
{ RS(MEM_MAPPED) },
|
|
|
|
|
{ RS(MEM_NFS_UNSTABLE) },
|
|
|
|
|
{ RS(MEM_PAGE_TABLES) },
|
|
|
|
|
{ RS(MEM_SHARED) },
|
|
|
|
|
{ RS(MEM_SLAB) },
|
|
|
|
|
{ RS(MEM_SLAB_RECLAIM) },
|
|
|
|
|
{ RS(MEM_SLAB_UNRECLAIM) },
|
|
|
|
|
{ RS(MEM_TOTAL) },
|
|
|
|
|
{ RS(MEM_UNEVICTABLE) },
|
|
|
|
|
{ RS(MEM_USED) },
|
|
|
|
|
{ RS(MEM_VM_ALLOC_CHUNK) },
|
|
|
|
|
{ RS(MEM_VM_ALLOC_TOTAL) },
|
|
|
|
|
{ RS(MEM_VM_ALLOC_USED) },
|
|
|
|
|
{ RS(MEM_WRITEBACK) },
|
|
|
|
|
{ RS(MEM_WRITEBACK_TMP) },
|
|
|
|
|
|
|
|
|
|
{ RS(DELTA_ACTIVE) },
|
|
|
|
|
{ RS(DELTA_ACTIVE_ANON) },
|
|
|
|
|
{ RS(DELTA_ACTIVE_FILE) },
|
|
|
|
|
{ RS(DELTA_ANON) },
|
|
|
|
|
{ RS(DELTA_AVAILABLE) },
|
|
|
|
|
{ RS(DELTA_BOUNCE) },
|
|
|
|
|
{ RS(DELTA_BUFFERS) },
|
|
|
|
|
{ RS(DELTA_CACHED) },
|
|
|
|
|
{ RS(DELTA_COMMIT_LIMIT) },
|
|
|
|
|
{ RS(DELTA_COMMITTED_AS) },
|
|
|
|
|
{ RS(DELTA_HARD_CORRUPTED) },
|
|
|
|
|
{ RS(DELTA_DIRTY) },
|
|
|
|
|
{ RS(DELTA_FREE) },
|
|
|
|
|
{ RS(DELTA_HUGE_ANON) },
|
|
|
|
|
{ RS(DELTA_HUGE_FREE) },
|
|
|
|
|
{ RS(DELTA_HUGE_RSVD) },
|
|
|
|
|
{ RS(DELTA_HUGE_SIZE) },
|
|
|
|
|
{ RS(DELTA_HUGE_SURPLUS) },
|
|
|
|
|
{ RS(DELTA_HUGE_TOTAL) },
|
|
|
|
|
{ RS(DELTA_INACTIVE) },
|
|
|
|
|
{ RS(DELTA_INACTIVE_ANON) },
|
|
|
|
|
{ RS(DELTA_INACTIVE_FILE) },
|
|
|
|
|
{ RS(DELTA_KERNEL_STACK) },
|
|
|
|
|
{ RS(DELTA_LOCKED) },
|
|
|
|
|
{ RS(DELTA_MAPPED) },
|
|
|
|
|
{ RS(DELTA_NFS_UNSTABLE) },
|
|
|
|
|
{ RS(DELTA_PAGE_TABLES) },
|
|
|
|
|
{ RS(DELTA_SHARED) },
|
|
|
|
|
{ RS(DELTA_SLAB) },
|
|
|
|
|
{ RS(DELTA_SLAB_RECLAIM) },
|
|
|
|
|
{ RS(DELTA_SLAB_UNRECLAIM) },
|
|
|
|
|
{ RS(DELTA_TOTAL) },
|
|
|
|
|
{ RS(DELTA_UNEVICTABLE) },
|
|
|
|
|
{ RS(DELTA_USED) },
|
|
|
|
|
{ RS(DELTA_VM_ALLOC_CHUNK) },
|
|
|
|
|
{ RS(DELTA_VM_ALLOC_TOTAL) },
|
|
|
|
|
{ RS(DELTA_VM_ALLOC_USED) },
|
|
|
|
|
{ RS(DELTA_WRITEBACK) },
|
|
|
|
|
{ RS(DELTA_WRITEBACK_TMP) },
|
|
|
|
|
|
|
|
|
|
{ RS(MEMHI_FREE) },
|
|
|
|
|
{ RS(MEMHI_TOTAL) },
|
|
|
|
|
{ RS(MEMHI_USED) },
|
|
|
|
|
{ RS(MEMLO_FREE) },
|
|
|
|
|
{ RS(MEMLO_TOTAL) },
|
|
|
|
|
{ RS(MEMLO_USED) },
|
|
|
|
|
|
|
|
|
|
{ RS(SWAP_CACHED) },
|
|
|
|
|
{ RS(SWAP_FREE) },
|
|
|
|
|
{ RS(SWAP_TOTAL) },
|
|
|
|
|
{ RS(SWAP_USED) },
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2016-06-09 10:30:00 +05:30
|
|
|
// dummy entry corresponding to PROCPS_MEMINFO_logical_end ...
|
2016-06-18 10:30:00 +05:30
|
|
|
{ NULL, }
|
2015-06-20 18:38:47 +05:30
|
|
|
};
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* please note,
|
|
|
|
|
* this enum MUST be 1 greater than the highest value of any enum */
|
|
|
|
|
enum meminfo_item PROCPS_MEMINFO_logical_end = PROCPS_MEMINFO_SWAP_USED + 1;
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
#undef setNAME
|
2016-06-06 10:30:00 +05:30
|
|
|
#undef RS
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
static inline void assign_results (
|
|
|
|
|
struct meminfo_stack *stack,
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
struct mem_hist *hist)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
2016-05-11 22:30:00 +05:30
|
|
|
struct meminfo_result *this = stack->head;
|
|
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
|
enum meminfo_item item = this->item;
|
|
|
|
|
if (item >= PROCPS_MEMINFO_logical_end)
|
|
|
|
|
break;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
Item_table[item].setsfunc(this, hist);
|
2016-05-11 22:30:00 +05:30
|
|
|
++this;
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
} // end: assign_results
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline void cleanup_stack (
|
|
|
|
|
struct meminfo_result *this)
|
|
|
|
|
{
|
|
|
|
|
for (;;) {
|
|
|
|
|
if (this->item >= PROCPS_MEMINFO_logical_end)
|
|
|
|
|
break;
|
|
|
|
|
if (this->item > PROCPS_MEMINFO_noop)
|
2016-05-12 10:30:00 +05:30
|
|
|
this->result.ul_int = 0;
|
2016-05-11 22:30:00 +05:30
|
|
|
++this;
|
|
|
|
|
}
|
|
|
|
|
} // end: cleanup_stack
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline void cleanup_stacks_all (
|
|
|
|
|
struct procps_meminfo *info)
|
|
|
|
|
{
|
|
|
|
|
struct stacks_extent *ext = info->extents;
|
2016-07-07 10:30:00 +05:30
|
|
|
int i;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
while (ext) {
|
|
|
|
|
for (i = 0; ext->stacks[i]; i++)
|
|
|
|
|
cleanup_stack(ext->stacks[i]->head);
|
|
|
|
|
ext = ext->next;
|
|
|
|
|
};
|
|
|
|
|
info->dirty_stacks = 0;
|
|
|
|
|
} // end: cleanup_stacks_all
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void extents_free_all (
|
|
|
|
|
struct procps_meminfo *info)
|
|
|
|
|
{
|
2016-07-01 10:30:00 +05:30
|
|
|
while (info->extents) {
|
2016-05-11 22:30:00 +05:30
|
|
|
struct stacks_extent *p = info->extents;
|
|
|
|
|
info->extents = info->extents->next;
|
|
|
|
|
free(p);
|
2016-07-01 10:30:00 +05:30
|
|
|
};
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: extents_free_all
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline struct meminfo_result *itemize_stack (
|
|
|
|
|
struct meminfo_result *p,
|
|
|
|
|
int depth,
|
|
|
|
|
enum meminfo_item *items)
|
|
|
|
|
{
|
|
|
|
|
struct meminfo_result *p_sav = p;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < depth; i++) {
|
|
|
|
|
p->item = items[i];
|
|
|
|
|
p->result.ul_int = 0;
|
|
|
|
|
++p;
|
|
|
|
|
}
|
|
|
|
|
return p_sav;
|
|
|
|
|
} // end: itemize_stack
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline int items_check_failed (
|
|
|
|
|
int numitems,
|
|
|
|
|
enum meminfo_item *items)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* if an enum is passed instead of an address of one or more enums, ol' gcc
|
|
|
|
|
* will silently convert it to an address (possibly NULL). only clang will
|
|
|
|
|
* offer any sort of warning like the following:
|
|
|
|
|
*
|
|
|
|
|
* warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'enum meminfo_item *'
|
|
|
|
|
* my_stack = procps_meminfo_select(info, PROCPS_MEMINFO_noop, num);
|
2016-06-01 10:30:00 +05:30
|
|
|
* ^~~~~~~~~~~~~~~~
|
2016-05-11 22:30:00 +05:30
|
|
|
*/
|
|
|
|
|
if (numitems < 1
|
|
|
|
|
|| (void *)items < (void *)(unsigned long)(2 * PROCPS_MEMINFO_logical_end))
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < numitems; i++) {
|
|
|
|
|
// a meminfo_item is currently unsigned, but we'll protect our future
|
|
|
|
|
if (items[i] < 0)
|
|
|
|
|
return -1;
|
|
|
|
|
if (items[i] >= PROCPS_MEMINFO_logical_end)
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2015-06-20 18:38:47 +05:30
|
|
|
|
|
|
|
|
return 0;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: items_check_failed
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
static int make_hash_failed (
|
|
|
|
|
struct procps_meminfo *info)
|
|
|
|
|
{
|
|
|
|
|
#define htVAL(f) e.key = STRINGIFY(f) ":"; e.data = &info->hist.new. f; \
|
|
|
|
|
if (!hsearch_r(e, ENTER, &ep, &info->hashtab)) return -errno;
|
|
|
|
|
#define htXTRA(k,f) e.key = STRINGIFY(k) ":"; e.data = &info->hist.new. f; \
|
|
|
|
|
if (!hsearch_r(e, ENTER, &ep, &info->hashtab)) return -errno;
|
|
|
|
|
ENTRY e, *ep;
|
|
|
|
|
size_t n;
|
|
|
|
|
|
|
|
|
|
// will also include those 4 derived fields (more is better)
|
|
|
|
|
n = sizeof(struct meminfo_data) / sizeof(unsigned long);
|
|
|
|
|
// we'll follow the hsearch recommendation of an extra 25%
|
|
|
|
|
hcreate_r(n + (n / 4), &info->hashtab);
|
|
|
|
|
|
|
|
|
|
htVAL(Active)
|
|
|
|
|
htXTRA(Active(anon), Active_anon)
|
|
|
|
|
htXTRA(Active(file), Active_file)
|
|
|
|
|
htVAL(AnonHugePages)
|
|
|
|
|
htVAL(AnonPages)
|
|
|
|
|
htVAL(Bounce)
|
|
|
|
|
htVAL(Buffers)
|
|
|
|
|
htVAL(Cached)
|
|
|
|
|
htVAL(CmaFree)
|
|
|
|
|
htVAL(CmaTotal)
|
|
|
|
|
htVAL(CommitLimit)
|
|
|
|
|
htVAL(Committed_AS)
|
|
|
|
|
htVAL(DirectMap1G)
|
|
|
|
|
htVAL(DirectMap2M)
|
|
|
|
|
htVAL(DirectMap4k)
|
|
|
|
|
htVAL(Dirty)
|
|
|
|
|
htVAL(HardwareCorrupted)
|
|
|
|
|
htVAL(HighFree)
|
|
|
|
|
htVAL(HighTotal)
|
|
|
|
|
htVAL(HugePages_Free)
|
|
|
|
|
htVAL(HugePages_Rsvd)
|
|
|
|
|
htVAL(HugePages_Surp)
|
|
|
|
|
htVAL(HugePages_Total)
|
|
|
|
|
htVAL(Hugepagesize)
|
|
|
|
|
htVAL(Inactive)
|
|
|
|
|
htXTRA(Inactive(anon), Inactive_anon)
|
|
|
|
|
htXTRA(Inactive(file), Inactive_file)
|
|
|
|
|
htVAL(KernelStack)
|
|
|
|
|
htVAL(LowFree)
|
|
|
|
|
htVAL(LowTotal)
|
|
|
|
|
htVAL(Mapped)
|
|
|
|
|
htVAL(MemAvailable)
|
|
|
|
|
htVAL(MemFree)
|
|
|
|
|
htVAL(MemTotal)
|
|
|
|
|
htVAL(Mlocked)
|
|
|
|
|
htVAL(NFS_Unstable)
|
|
|
|
|
htVAL(PageTables)
|
|
|
|
|
htVAL(SReclaimable)
|
|
|
|
|
htVAL(SUnreclaim)
|
|
|
|
|
htVAL(Shmem)
|
|
|
|
|
htVAL(Slab)
|
|
|
|
|
htVAL(SwapCached)
|
|
|
|
|
htVAL(SwapFree)
|
|
|
|
|
htVAL(SwapTotal)
|
|
|
|
|
htVAL(Unevictable)
|
|
|
|
|
htVAL(VmallocChunk)
|
|
|
|
|
htVAL(VmallocTotal)
|
|
|
|
|
htVAL(VmallocUsed)
|
|
|
|
|
htVAL(Writeback)
|
|
|
|
|
htVAL(WritebackTmp)
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
#undef htVAL
|
|
|
|
|
#undef htXTRA
|
|
|
|
|
} // end: make_hash_failed
|
|
|
|
|
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
/*
|
2016-05-11 22:30:00 +05:30
|
|
|
* read_meminfo_failed():
|
2015-06-20 18:38:47 +05:30
|
|
|
*
|
|
|
|
|
* Read the data out of /proc/meminfo putting the information
|
|
|
|
|
* into the supplied info structure
|
|
|
|
|
*/
|
2016-07-03 10:30:00 +05:30
|
|
|
static int read_meminfo_failed (
|
2015-06-28 10:30:00 +05:30
|
|
|
struct procps_meminfo *info)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
2016-05-11 22:30:00 +05:30
|
|
|
/* a 'memory history reference' macro for readability,
|
|
|
|
|
so we can focus the field names ... */
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
#define mHr(f) info->hist.new. f
|
2015-06-20 18:38:47 +05:30
|
|
|
char buf[8192];
|
|
|
|
|
char *head, *tail;
|
|
|
|
|
int size;
|
|
|
|
|
unsigned long *valptr;
|
2015-06-28 10:30:00 +05:30
|
|
|
signed long mem_used;
|
2015-06-20 18:38:47 +05:30
|
|
|
|
|
|
|
|
if (info == NULL)
|
2015-06-28 10:30:00 +05:30
|
|
|
return -1;
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
// remember history from last time around
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
memcpy(&info->hist.old, &info->hist.new, sizeof(struct meminfo_data));
|
2016-05-11 22:30:00 +05:30
|
|
|
// clear out the soon to be 'current' values
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
memset(&info->hist.new, 0, sizeof(struct meminfo_data));
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (-1 == info->meminfo_fd
|
|
|
|
|
&& (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)) == -1)
|
2015-06-28 10:30:00 +05:30
|
|
|
return -errno;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
|
2015-06-28 10:30:00 +05:30
|
|
|
return -errno;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
for (;;) {
|
|
|
|
|
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
|
|
|
|
|
if (errno == EINTR || errno == EAGAIN)
|
|
|
|
|
continue;
|
|
|
|
|
return -errno;
|
|
|
|
|
}
|
|
|
|
|
break;
|
2015-06-20 18:38:47 +05:30
|
|
|
}
|
2015-06-28 10:30:00 +05:30
|
|
|
if (size == 0)
|
2016-07-03 10:30:00 +05:30
|
|
|
return -1;
|
2015-06-20 18:38:47 +05:30
|
|
|
buf[size] = '\0';
|
|
|
|
|
|
|
|
|
|
head = buf;
|
2016-07-03 10:30:00 +05:30
|
|
|
for (;;) {
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
static ENTRY e; // just to keep coverity off our backs (e.data)
|
|
|
|
|
ENTRY *ep;
|
|
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
tail = strchr(head, ' ');
|
|
|
|
|
if (!tail)
|
|
|
|
|
break;
|
|
|
|
|
*tail = '\0';
|
|
|
|
|
valptr = NULL;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
|
|
|
|
|
e.key = head;
|
|
|
|
|
if (hsearch_r(e, FIND, &ep, &info->hashtab))
|
|
|
|
|
valptr = ep->data;
|
|
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
head = tail+1;
|
2016-07-03 10:30:00 +05:30
|
|
|
if (valptr)
|
2015-06-28 10:30:00 +05:30
|
|
|
*valptr = strtoul(head, &tail, 10);
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
tail = strchr(head, '\n');
|
|
|
|
|
if (!tail)
|
|
|
|
|
break;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
|
2015-06-28 10:30:00 +05:30
|
|
|
head = tail + 1;
|
2016-07-03 10:30:00 +05:30
|
|
|
}
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (0 == mHr(MemAvailable))
|
|
|
|
|
mHr(MemAvailable) = mHr(MemFree);
|
2015-06-28 10:30:00 +05:30
|
|
|
/* if 'available' is greater than 'total' or our calculation of mem_used
|
|
|
|
|
overflows, that's symptomatic of running within a lxc container where
|
|
|
|
|
such values will be dramatically distorted over those of the host. */
|
2016-05-11 22:30:00 +05:30
|
|
|
if (mHr(MemAvailable) > mHr(MemTotal))
|
|
|
|
|
mHr(MemAvailable) = mHr(MemFree);
|
|
|
|
|
|
|
|
|
|
mem_used = mHr(MemTotal) - mHr(MemFree) - mHr(Cached) - mHr(Buffers);
|
2015-06-28 10:30:00 +05:30
|
|
|
if (mem_used < 0)
|
2016-05-11 22:30:00 +05:30
|
|
|
mem_used = mHr(MemTotal) - mHr(MemFree);
|
|
|
|
|
mHr(derived_mem_used) = (unsigned long)mem_used;
|
|
|
|
|
|
|
|
|
|
if (mHr(HighFree) < mHr(HighTotal))
|
|
|
|
|
mHr(derived_mem_hi_used) = mHr(HighTotal) - mHr(HighFree);
|
|
|
|
|
|
|
|
|
|
mHr(Cached) += mHr(SReclaimable);
|
|
|
|
|
|
|
|
|
|
if (0 == mHr(LowTotal)) {
|
|
|
|
|
mHr(LowTotal) = mHr(MemTotal);
|
|
|
|
|
mHr(LowFree) = mHr(MemFree);
|
|
|
|
|
}
|
|
|
|
|
if (mHr(LowFree) < mHr(LowTotal))
|
|
|
|
|
mHr(derived_mem_lo_used) = mHr(LowTotal) - mHr(LowFree);
|
|
|
|
|
|
|
|
|
|
if (mHr(SwapFree) < mHr(SwapTotal))
|
|
|
|
|
mHr(derived_swap_used) = mHr(SwapTotal) - mHr(SwapFree);
|
|
|
|
|
|
|
|
|
|
// let's not distort the deltas the first time thru ...
|
|
|
|
|
if (!info->meminfo_was_read)
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
memcpy(&info->hist.old, &info->hist.new, sizeof(struct meminfo_data));
|
2016-05-11 22:30:00 +05:30
|
|
|
info->meminfo_was_read = 1;
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
return 0;
|
2016-05-11 22:30:00 +05:30
|
|
|
#undef mHr
|
|
|
|
|
} // end: read_meminfo_failed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* stacks_alloc():
|
|
|
|
|
*
|
|
|
|
|
* Allocate and initialize one or more stacks each of which is anchored in an
|
|
|
|
|
* associated meminfo_stack structure.
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
static struct stacks_extent *stacks_alloc (
|
|
|
|
|
struct procps_meminfo *info,
|
|
|
|
|
int maxstacks)
|
|
|
|
|
{
|
|
|
|
|
struct stacks_extent *p_blob;
|
|
|
|
|
struct meminfo_stack **p_vect;
|
|
|
|
|
struct meminfo_stack *p_head;
|
|
|
|
|
size_t vect_size, head_size, list_size, blob_size;
|
|
|
|
|
void *v_head, *v_list;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (info == NULL || info->items == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
if (maxstacks < 1)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
vect_size = sizeof(void *) * maxstacks; // size of the addr vectors |
|
|
|
|
|
vect_size += sizeof(void *); // plus NULL addr delimiter |
|
|
|
|
|
head_size = sizeof(struct meminfo_stack); // size of that head struct |
|
|
|
|
|
list_size = sizeof(struct meminfo_result)*info->numitems; // any single results stack |
|
|
|
|
|
blob_size = sizeof(struct stacks_extent); // the extent anchor itself |
|
|
|
|
|
blob_size += vect_size; // plus room for addr vects |
|
|
|
|
|
blob_size += head_size * maxstacks; // plus room for head thing |
|
|
|
|
|
blob_size += list_size * maxstacks; // plus room for our stacks |
|
|
|
|
|
|
|
|
|
|
/* note: all of 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 meminfo_stack *)v_head;
|
|
|
|
|
p_head->head = itemize_stack((struct meminfo_result *)v_list, info->numitems, info->items);
|
|
|
|
|
p_blob->stacks[i] = p_head;
|
|
|
|
|
v_list += list_size;
|
|
|
|
|
v_head += head_size;
|
|
|
|
|
}
|
|
|
|
|
p_blob->ext_numstacks = maxstacks;
|
|
|
|
|
return p_blob;
|
|
|
|
|
} // end: stacks_alloc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
// --- standard required functions --------------------------------------------
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/*
|
|
|
|
|
* procps_meminfo_new:
|
|
|
|
|
*
|
|
|
|
|
* Create a new container to hold the stat information
|
|
|
|
|
*
|
|
|
|
|
* The initial refcount is 1, and needs to be decremented
|
|
|
|
|
* to release the resources of the structure.
|
|
|
|
|
*
|
|
|
|
|
* Returns: a pointer to a new meminfo struct
|
|
|
|
|
*/
|
|
|
|
|
PROCPS_EXPORT int procps_meminfo_new (
|
|
|
|
|
struct procps_meminfo **info)
|
|
|
|
|
{
|
|
|
|
|
struct procps_meminfo *p;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
int rc;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
|
|
|
|
if (info == NULL || *info != NULL)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
if (!(p = calloc(1, sizeof(struct procps_meminfo))))
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
p->refcount = 1;
|
|
|
|
|
p->meminfo_fd = -1;
|
|
|
|
|
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
if ((rc = make_hash_failed(p))) {
|
|
|
|
|
free(p);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
*info = p;
|
|
|
|
|
return 0;
|
|
|
|
|
} // end: procps_meminfo_new
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
PROCPS_EXPORT int procps_meminfo_ref (
|
2015-06-28 10:30:00 +05:30
|
|
|
struct procps_meminfo *info)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
|
|
|
|
if (info == NULL)
|
2015-06-30 10:30:00 +05:30
|
|
|
return -EINVAL;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
info->refcount++;
|
2015-06-30 10:30:00 +05:30
|
|
|
return info->refcount;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: procps_meminfo_ref
|
|
|
|
|
|
2015-06-20 18:38:47 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
PROCPS_EXPORT int procps_meminfo_unref (
|
|
|
|
|
struct procps_meminfo **info)
|
2015-06-20 18:38:47 +05:30
|
|
|
{
|
2015-06-30 10:30:00 +05:30
|
|
|
if (info == NULL || *info == NULL)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
(*info)->refcount--;
|
2016-05-11 22:30:00 +05:30
|
|
|
|
2015-06-30 10:30:00 +05:30
|
|
|
if ((*info)->refcount == 0) {
|
2016-05-11 22:30:00 +05:30
|
|
|
if ((*info)->extents)
|
|
|
|
|
extents_free_all((*info));
|
|
|
|
|
if ((*info)->items)
|
|
|
|
|
free((*info)->items);
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
hdestroy_r(&(*info)->hashtab);
|
2015-06-30 10:30:00 +05:30
|
|
|
free(*info);
|
|
|
|
|
*info = NULL;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
return (*info)->refcount;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: procps_meminfo_unref
|
2015-06-28 10:30:00 +05:30
|
|
|
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-06-14 10:30:00 +05:30
|
|
|
// --- variable interface functions -------------------------------------------
|
|
|
|
|
|
2016-06-18 10:30:00 +05:30
|
|
|
PROCPS_EXPORT struct meminfo_result *procps_meminfo_get (
|
2015-07-11 10:30:00 +05:30
|
|
|
struct procps_meminfo *info,
|
2016-05-11 22:30:00 +05:30
|
|
|
enum meminfo_item item)
|
2015-07-11 10:30:00 +05:30
|
|
|
{
|
2016-05-11 22:30:00 +05:30
|
|
|
static time_t sav_secs;
|
|
|
|
|
time_t cur_secs;
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-06-01 10:30:00 +05:30
|
|
|
if (info == NULL)
|
2016-06-18 10:30:00 +05:30
|
|
|
return NULL;
|
2016-06-01 10:30:00 +05:30
|
|
|
if (item < 0 || item >= PROCPS_MEMINFO_logical_end)
|
2016-06-18 10:30:00 +05:30
|
|
|
return NULL;
|
2016-06-01 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* we will NOT read the meminfo file with every call - rather, we'll offer
|
|
|
|
|
a granularity of 1 second between reads ... */
|
|
|
|
|
cur_secs = time(NULL);
|
|
|
|
|
if (1 <= cur_secs - sav_secs) {
|
2016-06-18 10:30:00 +05:30
|
|
|
if (read_meminfo_failed(info))
|
|
|
|
|
return NULL;
|
2016-05-11 22:30:00 +05:30
|
|
|
sav_secs = cur_secs;
|
2015-07-11 10:30:00 +05:30
|
|
|
}
|
|
|
|
|
|
2016-06-18 10:30:00 +05:30
|
|
|
info->get_this.item = item;
|
|
|
|
|
// with 'get', we must NOT honor the usual 'noop' guarantee
|
|
|
|
|
// if (item > PROCPS_MEMINFO_noop)
|
|
|
|
|
info->get_this.result.ul_int = 0;
|
|
|
|
|
Item_table[item].setsfunc(&info->get_this, &info->hist);
|
|
|
|
|
|
|
|
|
|
return &info->get_this;
|
2016-05-11 22:30:00 +05:30
|
|
|
} // end: procps_meminfo_get
|
2015-07-21 10:30:00 +05:30
|
|
|
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* procps_meminfo_select():
|
2015-07-11 10:30:00 +05:30
|
|
|
*
|
2016-05-11 22:30:00 +05:30
|
|
|
* Harvest all the requested MEM and/or SWAP information then return
|
|
|
|
|
* it in a results stack.
|
|
|
|
|
*
|
|
|
|
|
* Returns: pointer to a meminfo_stack struct on success, NULL on error.
|
2015-07-11 10:30:00 +05:30
|
|
|
*/
|
2016-05-11 22:30:00 +05:30
|
|
|
PROCPS_EXPORT struct meminfo_stack *procps_meminfo_select (
|
2015-07-11 10:30:00 +05:30
|
|
|
struct procps_meminfo *info,
|
2016-05-11 22:30:00 +05:30
|
|
|
enum meminfo_item *items,
|
|
|
|
|
int numitems)
|
2015-07-11 10:30:00 +05:30
|
|
|
{
|
|
|
|
|
if (info == NULL || items == NULL)
|
|
|
|
|
return NULL;
|
2016-05-11 22:30:00 +05:30
|
|
|
if (items_check_failed(numitems, items))
|
2015-07-11 10:30:00 +05:30
|
|
|
return NULL;
|
|
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
/* is this the first time or have things changed since we were last called?
|
|
|
|
|
if so, gotta' redo all of our stacks stuff ... */
|
|
|
|
|
if (info->numitems != numitems + 1
|
|
|
|
|
|| memcmp(info->items, items, sizeof(enum meminfo_item) * numitems)) {
|
|
|
|
|
// allow for our PROCPS_MEMINFO_logical_end
|
|
|
|
|
if (!(info->items = realloc(info->items, sizeof(enum meminfo_item) * (numitems + 1))))
|
2016-05-12 03:22:36 +05:30
|
|
|
return NULL;
|
2016-05-11 22:30:00 +05:30
|
|
|
memcpy(info->items, items, sizeof(enum meminfo_item) * numitems);
|
|
|
|
|
info->items[numitems] = PROCPS_MEMINFO_logical_end;
|
|
|
|
|
info->numitems = numitems + 1;
|
|
|
|
|
if (info->extents)
|
|
|
|
|
extents_free_all(info);
|
2015-07-11 10:30:00 +05:30
|
|
|
}
|
2016-05-11 22:30:00 +05:30
|
|
|
if (!info->extents
|
2016-06-06 10:30:00 +05:30
|
|
|
&& !(stacks_alloc(info, 1)))
|
2016-05-11 22:30:00 +05:30
|
|
|
return NULL;
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (info->dirty_stacks)
|
|
|
|
|
cleanup_stacks_all(info);
|
2015-07-11 10:30:00 +05:30
|
|
|
|
2016-05-11 22:30:00 +05:30
|
|
|
if (read_meminfo_failed(info))
|
2015-07-11 10:30:00 +05:30
|
|
|
return NULL;
|
library: file now parsed with 'hsearch', <MEMINFO> api
After reviewing the hsearch code in glibc, performance
will almost certainly benefit from abandoning a strcmp
approach in favor of hashing, just like that <vmstat>.
[ As an aside, now having struggled toward that goal ]
[ of opaqueness & making our API as user friendly as ]
[ possible, haven't we earned the rights to evaluate ]
[ other implementations? For example, GNU's hsearch? ]
[ We expose none of our 'info' struct details to the ]
[ users, but GNU exposes their 'hsearch_data' thingy ]
[ right there in <search.h>. But worse, they require ]
[ the user to zero it out before 1st use. Jeeze, you ]
[ mean that a function called hcreate_r could not do ]
[ its own memset? Aw, come on GNU! What's with that? ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
|
|
|
assign_results(info->extents->stacks[0], &info->hist);
|
2016-05-11 22:30:00 +05:30
|
|
|
info->dirty_stacks = 1;
|
|
|
|
|
|
|
|
|
|
return info->extents->stacks[0];
|
|
|
|
|
} // end: procps_meminfo_select
|
