emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
904f4c3b35
procps/proc/meminfo.c

936 lines
30 KiB
C
Raw Normal View History

library: memory and vmstat API changes Created new set of functions for meminfo related calls. Liked the format of that better so changed vmstat around so the look similar. Missed the makefile change for uptime so added it in now.
2015-06-21 13:52:28 +05:30
/*
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
* libprocps - Library to read proc filesystem
library: memory and vmstat API changes Created new set of functions for meminfo related calls. Liked the format of that better so changed vmstat around so the look similar. Missed the makefile change for uptime so added it in now.
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
*/
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#include <errno.h>
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
#include <fcntl.h>
library: 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>
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#include <stdio.h>
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#include <stdlib.h>
#include <string.h>
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#include <time.h>
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#include <unistd.h>
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#include <sys/stat.h>
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
#include <sys/types.h>
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: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#include <proc/procps-private.h>
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#include <proc/meminfo.h>
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#define MEMINFO_FILE "/proc/meminfo"
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
struct meminfo_data {
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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):
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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'
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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'
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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):
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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;
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
unsigned long ShmemHugePages;
unsigned long ShmemPmdMapped;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
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 {
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +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 meminfo_info {
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
int refcount;
int meminfo_fd;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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;
library: <MEMINFO> api, changed that '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 meminfo_result get_this;
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
};
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
#define setNAME(e) set_meminfo_ ## e
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#define setDECL(e) static void setNAME(e) \
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
(struct meminfo_result *R, struct mem_hist *H)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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
library: ain't like your father's delta, <MEMINFO> api When the code for DELTA values (among other stuff) was stolen from the recently revised <stat> interface, the concept of ever growing values was propagated too. But here we must manage both growing and shrinking values. Thus former protections against a negative delta don't have any place in this module and are hereby banished. Signed-off-by: Jim Warner <james.warner@comcast.net>
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 ); }
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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)
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
MEM_set(MEM_SHMEM_HUGE, ul_int, ShmemHugePages)
MEM_set(MEM_SHMEM_HUGE_MAP, ul_int, ShmemPmdMapped)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
MEM_set(MEM_SLAB, ul_int, Slab)
MEM_set(MEM_SLAB_RECLAIM, ul_int, SReclaimable)
MEM_set(MEM_SLAB_UNRECLAIM, ul_int, SUnreclaim)
MEM_set(MEM_TOTAL, ul_int, MemTotal)
MEM_set(MEM_UNEVICTABLE, ul_int, Unevictable)
MEM_set(MEM_USED, ul_int, derived_mem_used)
MEM_set(MEM_VM_ALLOC_CHUNK, ul_int, VmallocChunk)
library: remove the ull_int result type, <MEMINFO> api Because of the vast quantities of virtual memory which may be allocated, it initially seemed like a good idea to provide for a widest possible range through the use of a 'ull_int' result type. However, on second thought the implementation was a bit flawed for these reasons: . that underlying meminfo_data variable 'VmallocTotal' is 'unsigned long' not a required 'unsigned long long' . there wasn't a convenient way to value it since each variable was set with a strtoul() call, not strtoull() So this patch will standardize on the 'ul_int' results type (and reduce the associated delta to 's_int' too). For now, we'll rely on protections under a 64-bit arch where a 'ull_int' & 'ul_int' yield identical capacity. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 10:30:00 +05:30
MEM_set(MEM_VM_ALLOC_TOTAL, ul_int, VmallocTotal)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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)
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
HST_set(DELTA_SHMEM_HUGE, s_int, ShmemHugePages)
HST_set(DELTA_SHMEM_HUGE_MAP, s_int, ShmemPmdMapped)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
HST_set(DELTA_SLAB, s_int, Slab)
HST_set(DELTA_SLAB_RECLAIM, s_int, SReclaimable)
HST_set(DELTA_SLAB_UNRECLAIM, s_int, SUnreclaim)
HST_set(DELTA_TOTAL, s_int, MemTotal)
HST_set(DELTA_UNEVICTABLE, s_int, Unevictable)
HST_set(DELTA_USED, s_int, derived_mem_used)
HST_set(DELTA_VM_ALLOC_CHUNK, s_int, VmallocChunk)
library: remove the ull_int result type, <MEMINFO> api Because of the vast quantities of virtual memory which may be allocated, it initially seemed like a good idea to provide for a widest possible range through the use of a 'ull_int' result type. However, on second thought the implementation was a bit flawed for these reasons: . that underlying meminfo_data variable 'VmallocTotal' is 'unsigned long' not a required 'unsigned long long' . there wasn't a convenient way to value it since each variable was set with a strtoul() call, not strtoull() So this patch will standardize on the 'ul_int' results type (and reduce the associated delta to 's_int' too). For now, we'll rely on protections under a 64-bit arch where a 'ull_int' & 'ul_int' yield identical capacity. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 10:30:00 +05:30
HST_set(DELTA_VM_ALLOC_TOTAL, s_int, VmallocTotal)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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)
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
#undef setDECL
#undef MEM_set
#undef HST_set
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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 *);
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#define RS(e) (SET_t)setNAME(e)
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#define TS(t) STRINGIFY(t)
#define TS_noop ""
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
/*
* Need it be said?
* This table must be kept in the exact same order as
* those 'enum meminfo_item' guys ! */
static struct {
SET_t setsfunc; // the actual result setting routine
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
char *type2str; // the result type as a string value
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
} Item_table[] = {
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
/* setsfunc type2str
------------------------- ---------- */
{ RS(noop), TS_noop },
{ RS(extra), TS_noop },
{ RS(MEM_ACTIVE), TS(ul_int) },
{ RS(MEM_ACTIVE_ANON), TS(ul_int) },
{ RS(MEM_ACTIVE_FILE), TS(ul_int) },
{ RS(MEM_ANON), TS(ul_int) },
{ RS(MEM_AVAILABLE), TS(ul_int) },
{ RS(MEM_BOUNCE), TS(ul_int) },
{ RS(MEM_BUFFERS), TS(ul_int) },
{ RS(MEM_CACHED), TS(ul_int) },
{ RS(MEM_COMMIT_LIMIT), TS(ul_int) },
{ RS(MEM_COMMITTED_AS), TS(ul_int) },
{ RS(MEM_HARD_CORRUPTED), TS(ul_int) },
{ RS(MEM_DIRTY), TS(ul_int) },
{ RS(MEM_FREE), TS(ul_int) },
{ RS(MEM_HUGE_ANON), TS(ul_int) },
{ RS(MEM_HUGE_FREE), TS(ul_int) },
{ RS(MEM_HUGE_RSVD), TS(ul_int) },
{ RS(MEM_HUGE_SIZE), TS(ul_int) },
{ RS(MEM_HUGE_SURPLUS), TS(ul_int) },
{ RS(MEM_HUGE_TOTAL), TS(ul_int) },
{ RS(MEM_INACTIVE), TS(ul_int) },
{ RS(MEM_INACTIVE_ANON), TS(ul_int) },
{ RS(MEM_INACTIVE_FILE), TS(ul_int) },
{ RS(MEM_KERNEL_STACK), TS(ul_int) },
{ RS(MEM_LOCKED), TS(ul_int) },
{ RS(MEM_MAPPED), TS(ul_int) },
{ RS(MEM_NFS_UNSTABLE), TS(ul_int) },
{ RS(MEM_PAGE_TABLES), TS(ul_int) },
{ RS(MEM_SHARED), TS(ul_int) },
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
{ RS(MEM_SHMEM_HUGE), TS(ul_int) },
{ RS(MEM_SHMEM_HUGE_MAP), TS(ul_int) },
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ RS(MEM_SLAB), TS(ul_int) },
{ RS(MEM_SLAB_RECLAIM), TS(ul_int) },
{ RS(MEM_SLAB_UNRECLAIM), TS(ul_int) },
{ RS(MEM_TOTAL), TS(ul_int) },
{ RS(MEM_UNEVICTABLE), TS(ul_int) },
{ RS(MEM_USED), TS(ul_int) },
{ RS(MEM_VM_ALLOC_CHUNK), TS(ul_int) },
{ RS(MEM_VM_ALLOC_TOTAL), TS(ul_int) },
{ RS(MEM_VM_ALLOC_USED), TS(ul_int) },
{ RS(MEM_WRITEBACK), TS(ul_int) },
{ RS(MEM_WRITEBACK_TMP), TS(ul_int) },
{ RS(DELTA_ACTIVE), TS(s_int) },
{ RS(DELTA_ACTIVE_ANON), TS(s_int) },
{ RS(DELTA_ACTIVE_FILE), TS(s_int) },
{ RS(DELTA_ANON), TS(s_int) },
{ RS(DELTA_AVAILABLE), TS(s_int) },
{ RS(DELTA_BOUNCE), TS(s_int) },
{ RS(DELTA_BUFFERS), TS(s_int) },
{ RS(DELTA_CACHED), TS(s_int) },
{ RS(DELTA_COMMIT_LIMIT), TS(s_int) },
{ RS(DELTA_COMMITTED_AS), TS(s_int) },
{ RS(DELTA_HARD_CORRUPTED), TS(s_int) },
{ RS(DELTA_DIRTY), TS(s_int) },
{ RS(DELTA_FREE), TS(s_int) },
{ RS(DELTA_HUGE_ANON), TS(s_int) },
{ RS(DELTA_HUGE_FREE), TS(s_int) },
{ RS(DELTA_HUGE_RSVD), TS(s_int) },
{ RS(DELTA_HUGE_SIZE), TS(s_int) },
{ RS(DELTA_HUGE_SURPLUS), TS(s_int) },
{ RS(DELTA_HUGE_TOTAL), TS(s_int) },
{ RS(DELTA_INACTIVE), TS(s_int) },
{ RS(DELTA_INACTIVE_ANON), TS(s_int) },
{ RS(DELTA_INACTIVE_FILE), TS(s_int) },
{ RS(DELTA_KERNEL_STACK), TS(s_int) },
{ RS(DELTA_LOCKED), TS(s_int) },
{ RS(DELTA_MAPPED), TS(s_int) },
{ RS(DELTA_NFS_UNSTABLE), TS(s_int) },
{ RS(DELTA_PAGE_TABLES), TS(s_int) },
{ RS(DELTA_SHARED), TS(s_int) },
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
{ RS(DELTA_SHMEM_HUGE), TS(s_int) },
{ RS(DELTA_SHMEM_HUGE_MAP), TS(s_int) },
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ RS(DELTA_SLAB), TS(s_int) },
{ RS(DELTA_SLAB_RECLAIM), TS(s_int) },
{ RS(DELTA_SLAB_UNRECLAIM), TS(s_int) },
{ RS(DELTA_TOTAL), TS(s_int) },
{ RS(DELTA_UNEVICTABLE), TS(s_int) },
{ RS(DELTA_USED), TS(s_int) },
{ RS(DELTA_VM_ALLOC_CHUNK), TS(s_int) },
{ RS(DELTA_VM_ALLOC_TOTAL), TS(s_int) },
{ RS(DELTA_VM_ALLOC_USED), TS(s_int) },
{ RS(DELTA_WRITEBACK), TS(s_int) },
{ RS(DELTA_WRITEBACK_TMP), TS(s_int) },
{ RS(MEMHI_FREE), TS(ul_int) },
{ RS(MEMHI_TOTAL), TS(ul_int) },
{ RS(MEMHI_USED), TS(ul_int) },
{ RS(MEMLO_FREE), TS(ul_int) },
{ RS(MEMLO_TOTAL), TS(ul_int) },
{ RS(MEMLO_USED), TS(ul_int) },
{ RS(SWAP_CACHED), TS(ul_int) },
{ RS(SWAP_FREE), TS(ul_int) },
{ RS(SWAP_TOTAL), TS(ul_int) },
{ RS(SWAP_USED), TS(ul_int) },
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22: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
// dummy entry corresponding to MEMINFO_logical_end ...
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ NULL, NULL }
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
};
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
/* please note,
* this enum MUST be 1 greater than the highest value of any enum */
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
enum meminfo_item MEMINFO_logical_end = MEMINFO_SWAP_USED + 1;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#undef setNAME
library: whack a superfluous assignment, <MEMINFO> api This patch was prompted through work on the <slabinfo> upgrade from 2nd gen to 3rd. And while this assignment caused no real harm, it most certainly was misleading. [ plus add a couple of overlooked #undef directives! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
#undef RS
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline void meminfo_assign_results (
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
struct meminfo_stack *stack,
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
struct mem_hist *hist)
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
{
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
struct meminfo_result *this = stack->head;
for (;;) {
enum meminfo_item item = this->item;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (item >= MEMINFO_logical_end)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
break;
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
Item_table[item].setsfunc(this, hist);
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
++this;
}
return;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_assign_results
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline void meminfo_cleanup_stack (
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
struct meminfo_result *this)
{
for (;;) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (this->item >= MEMINFO_logical_end)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
break;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (this->item > MEMINFO_noop)
library: remove the ull_int result type, <MEMINFO> api Because of the vast quantities of virtual memory which may be allocated, it initially seemed like a good idea to provide for a widest possible range through the use of a 'ull_int' result type. However, on second thought the implementation was a bit flawed for these reasons: . that underlying meminfo_data variable 'VmallocTotal' is 'unsigned long' not a required 'unsigned long long' . there wasn't a convenient way to value it since each variable was set with a strtoul() call, not strtoull() So this patch will standardize on the 'ul_int' results type (and reduce the associated delta to 's_int' too). For now, we'll rely on protections under a 64-bit arch where a 'ull_int' & 'ul_int' yield identical capacity. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-12 10:30:00 +05:30
this->result.ul_int = 0;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
++this;
}
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_cleanup_stack
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline void meminfo_cleanup_stacks_all (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info *info)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
{
struct stacks_extent *ext = info->extents;
library: the overlooked twerks (oops, tweaks), 3rd gen Yes, all of these changes are strictly cosmetic. It is likely symptomatic of some deep-seated character flaw. [ or, it might be because of a certain pride in this ] [ new library and the desire to make it even better! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-07 10:30:00 +05:30
int i;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
while (ext) {
for (i = 0; ext->stacks[i]; i++)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
meminfo_cleanup_stack(ext->stacks[i]->head);
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
ext = ext->next;
};
info->dirty_stacks = 0;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_cleanup_stacks_all
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static void meminfo_extents_free_all (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info *info)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
{
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
while (info->extents) {
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
struct stacks_extent *p = info->extents;
info->extents = info->extents->next;
free(p);
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
};
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_extents_free_all
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline struct meminfo_result *meminfo_itemize_stack (
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
struct meminfo_result *p,
int depth,
enum meminfo_item *items)
{
struct meminfo_result *p_sav = p;
int i;
for (i = 0; i < depth; i++) {
p->item = items[i];
p->result.ul_int = 0;
++p;
}
return p_sav;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_itemize_stack
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline int meminfo_items_check_failed (
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
int numitems,
enum meminfo_item *items)
{
int i;
/* if an enum is passed instead of an address of one or more enums, ol' gcc
* will silently convert it to an address (possibly NULL). only clang will
* offer any sort of warning like the following:
*
* warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'enum meminfo_item *'
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
* my_stack = procps_meminfo_select(info, MEMINFO_noop, num);
library: add parameter checks for 'get', <MEMINFO> api When this interface was normalized/standardized, under the commit referenced below, the parameters were never validated in the 'get' function. Let's plug that hole. Reference(s): commit 407f1b71de3c4baed23d897b86ad316b64ad1ec9 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
* ^~~~~~~~~~~~~~~~
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
*/
if (numitems < 1
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|| (void *)items < (void *)(unsigned long)(2 * MEMINFO_logical_end))
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
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;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (items[i] >= MEMINFO_logical_end)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
return -1;
}
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
return 0;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_items_check_failed
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int meminfo_make_hash_failed (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info *info)
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
{
#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)
library: expand fields and break an ABI, <MEMINFO> api The immediately prior commit demonstrated how our APIs might be expanded in at some point in the future while maintaining binary compatibility in previous programs. However, since we've yet to release the 1st version of our new library, there's no need to violate alphabetic ordering just yet. So, this patch restores that order. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-11 21:41:11 +05:30
htVAL(ShmemHugePages)
htVAL(ShmemPmdMapped)
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
htVAL(Slab)
htVAL(SwapCached)
htVAL(SwapFree)
htVAL(SwapTotal)
htVAL(Unevictable)
htVAL(VmallocChunk)
htVAL(VmallocTotal)
htVAL(VmallocUsed)
htVAL(Writeback)
htVAL(WritebackTmp)
return 0;
#undef htVAL
#undef htXTRA
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_make_hash_failed
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
/*
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* meminfo_read_failed():
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
*
* Read the data out of /proc/meminfo putting the information
* into the supplied info structure
*/
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int meminfo_read_failed (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info *info)
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
{
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
char buf[8192];
char *head, *tail;
int size;
unsigned long *valptr;
library: add missing meminfo logic, improve efficiency This patch fills in some missing fields which have top dependencies. Additionally, I've tried to mirror those calculations Jaromir added for release 3.3.10. The one calculation that remains missing is 'available' memory for some kernels. For this API, we'll use a fall-back. Lastly the lxc safeguards which were recently added to the old procps library were incorporated here as well. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
signed long mem_used;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
if (info == NULL)
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
return -1;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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));
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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));
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (-1 == info->meminfo_fd
&& (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)) == -1)
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
return -errno;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
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
return -errno;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: make reads & unref logic a little more robust Since we are not using a higher level standard C fopen all of the read requests were made signal sensitive as that can result in a 'temporarily' failed i/o request. Also, protection against some user calling the 'unref' function on already free memory has been incorporated. This will protect us from some nasty 'Abort' surprise. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
for (;;) {
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return -errno;
}
break;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
}
library: make reads & unref logic a little more robust Since we are not using a higher level standard C fopen all of the read requests were made signal sensitive as that can result in a 'temporarily' failed i/o request. Also, protection against some user calling the 'unref' function on already free memory has been incorporated. This will protect us from some nasty 'Abort' surprise. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
if (size == 0)
library: some tweaks to 2 file read functions, 3rd gen Ever since their introduction, plus continuing through several evolutions, both the meminfo and vmstat 'read' functions employed a 'do while' loop for /proc access. However, that loop construct was wrong since identical tests were already done (twice!) within each loop body itself, then accompanied by its own 'break' statement. So, we will now transform them both into forever loops which will help us to emphasize such break statements. [ plus, let's return an error should nothing be read ] [ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ] Reference(s): . original meminfo introduction commit a20e88e4e72067c1138721c6e15e2d1130bc9595 . original vmstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-03 10:30:00 +05:30
return -1;
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
buf[size] = '\0';
head = buf;
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
library: some tweaks to 2 file read functions, 3rd gen Ever since their introduction, plus continuing through several evolutions, both the meminfo and vmstat 'read' functions employed a 'do while' loop for /proc access. However, that loop construct was wrong since identical tests were already done (twice!) within each loop body itself, then accompanied by its own 'break' statement. So, we will now transform them both into forever loops which will help us to emphasize such break statements. [ plus, let's return an error should nothing be read ] [ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ] Reference(s): . original meminfo introduction commit a20e88e4e72067c1138721c6e15e2d1130bc9595 . original vmstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-03 10:30:00 +05:30
for (;;) {
library: 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;
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
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;
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
head = tail+1;
library: some tweaks to 2 file read functions, 3rd gen Ever since their introduction, plus continuing through several evolutions, both the meminfo and vmstat 'read' functions employed a 'do while' loop for /proc access. However, that loop construct was wrong since identical tests were already done (twice!) within each loop body itself, then accompanied by its own 'break' statement. So, we will now transform them both into forever loops which will help us to emphasize such break statements. [ plus, let's return an error should nothing be read ] [ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ] Reference(s): . original meminfo introduction commit a20e88e4e72067c1138721c6e15e2d1130bc9595 . original vmstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-03 10:30:00 +05:30
if (valptr)
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
*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
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
tail = strchr(head, '\n');
if (!tail)
break;
head = tail + 1;
library: some tweaks to 2 file read functions, 3rd gen Ever since their introduction, plus continuing through several evolutions, both the meminfo and vmstat 'read' functions employed a 'do while' loop for /proc access. However, that loop construct was wrong since identical tests were already done (twice!) within each loop body itself, then accompanied by its own 'break' statement. So, we will now transform them both into forever loops which will help us to emphasize such break statements. [ plus, let's return an error should nothing be read ] [ lastly, eliminate 1 erroneous PROCPS_EXPORT prefix ] Reference(s): . original meminfo introduction commit a20e88e4e72067c1138721c6e15e2d1130bc9595 . original vmstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-03 10:30:00 +05:30
}
library: add missing meminfo logic, improve efficiency This patch fills in some missing fields which have top dependencies. Additionally, I've tried to mirror those calculations Jaromir added for release 3.3.10. The one calculation that remains missing is 'available' memory for some kernels. For this API, we'll use a fall-back. Lastly the lxc safeguards which were recently added to the old procps library were incorporated here as well. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (0 == mHr(MemAvailable))
mHr(MemAvailable) = mHr(MemFree);
library: add missing meminfo logic, improve efficiency This patch fills in some missing fields which have top dependencies. Additionally, I've tried to mirror those calculations Jaromir added for release 3.3.10. The one calculation that remains missing is 'available' memory for some kernels. For this API, we'll use a fall-back. Lastly the lxc safeguards which were recently added to the old procps library were incorporated here as well. Signed-off-by: Jim Warner <james.warner@comcast.net>
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. */
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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);
library: add missing meminfo logic, improve efficiency This patch fills in some missing fields which have top dependencies. Additionally, I've tried to mirror those calculations Jaromir added for release 3.3.10. The one calculation that remains missing is 'available' memory for some kernels. For this API, we'll use a fall-back. Lastly the lxc safeguards which were recently added to the old procps library were incorporated here as well. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
if (mem_used < 0)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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 ...
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
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));
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
info->meminfo_was_read = 1;
}
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
return 0;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
#undef mHr
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_read_failed
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
/*
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* meminfo_stacks_alloc():
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
*
* Allocate and initialize one or more stacks each of which is anchored in an
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* associated context structure.
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
*
* All such stacks will have their result structures properly primed with
* 'items', while the result itself will be zeroed.
*
* Returns a stacks_extent struct anchoring the 'heads' of each new stack.
*/
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static struct stacks_extent *meminfo_stacks_alloc (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info *info,
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
int maxstacks)
{
struct stacks_extent *p_blob;
struct meminfo_stack **p_vect;
struct meminfo_stack *p_head;
size_t vect_size, head_size, list_size, blob_size;
void *v_head, *v_list;
int i;
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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
p_head->head = meminfo_itemize_stack((struct meminfo_result *)v_list, info->numitems, info->items);
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
p_blob->stacks[i] = p_head;
v_list += list_size;
v_head += head_size;
}
p_blob->ext_numstacks = maxstacks;
return p_blob;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: meminfo_stacks_alloc
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
// --- standard required functions --------------------------------------------
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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.
*
library: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
* Returns: < 0 on failure, 0 on success along with
* a pointer to a new context struct
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
*/
PROCPS_EXPORT int procps_meminfo_new (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info **info)
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22: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 meminfo_info *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;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (info == NULL || *info != NULL)
return -EINVAL;
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (!(p = calloc(1, sizeof(struct meminfo_info))))
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
return -ENOMEM;
p->refcount = 1;
p->meminfo_fd = -1;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if ((rc = meminfo_make_hash_failed(p))) {
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
free(p);
return rc;
}
library: add priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 15:14:44 +05:30
/* do a priming read here for the following potential benefits: |
1) ensure there will be no problems with subsequent access |
2) make delta results potentially useful, even if 1st time | */
if ((rc = meminfo_read_failed(p))) {
procps_meminfo_unref(&p);
return rc;
}
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
*info = p;
return 0;
} // end: procps_meminfo_new
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
PROCPS_EXPORT int procps_meminfo_ref (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info *info)
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
{
if (info == NULL)
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
return -EINVAL;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
info->refcount++;
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
return info->refcount;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
} // end: procps_meminfo_ref
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
PROCPS_EXPORT int procps_meminfo_unref (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct meminfo_info **info)
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
{
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
if (info == NULL || *info == NULL)
return -EINVAL;
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
(*info)->refcount--;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
if ((*info)->refcount < 1) {
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if ((*info)->extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
meminfo_extents_free_all((*info));
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if ((*info)->items)
free((*info)->items);
library: file now parsed with 'hsearch', <MEMINFO> api After reviewing the hsearch code in glibc, performance will almost certainly benefit from abandoning a strcmp approach in favor of hashing, just like that <vmstat>. [ As an aside, now having struggled toward that goal ] [ of opaqueness & making our API as user friendly as ] [ possible, haven't we earned the rights to evaluate ] [ other implementations? For example, GNU's hsearch? ] [ We expose none of our 'info' struct details to the ] [ users, but GNU exposes their 'hsearch_data' thingy ] [ right there in <search.h>. But worse, they require ] [ the user to zero it out before 1st use. Jeeze, you ] [ mean that a function called hcreate_r could not do ] [ its own memset? Aw, come on GNU! What's with that? ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-10 10:30:00 +05:30
hdestroy_r(&(*info)->hashtab);
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
library: the uref functions were insufficiently robust The earlier attempt at protecting these functions from already freed memory worked just fine until the memory was, in fact, reused by the OS. At that point, the ref count would most likely fail an existing a test for 0. So this commit will take control of the 'info' pointer and force it to NULL when a reference count reaches 0. Plus, since it makes little sense returning an address that a caller already has, henceforth we will return a reference count out of the 'ref' and 'unref functions. Reference(s): commit 74beff80ff3624761ecd20fafac0485f48c9c873 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-30 10:30:00 +05:30
free(*info);
*info = NULL;
return 0;
}
return (*info)->refcount;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
} // end: procps_meminfo_unref
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: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
// --- variable interface functions -------------------------------------------
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
PROCPS_EXPORT struct meminfo_result *procps_meminfo_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 meminfo_info *info,
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
enum meminfo_item item)
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
{
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
static time_t sav_secs;
time_t cur_secs;
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: add parameter checks for 'get', <MEMINFO> api When this interface was normalized/standardized, under the commit referenced below, the parameters were never validated in the 'get' function. Let's plug that hole. Reference(s): commit 407f1b71de3c4baed23d897b86ad316b64ad1ec9 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
if (info == NULL)
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (item < 0 || item >= MEMINFO_logical_end)
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: add parameter checks for 'get', <MEMINFO> api When this interface was normalized/standardized, under the commit referenced below, the parameters were never validated in the 'get' function. Let's plug that hole. Reference(s): commit 407f1b71de3c4baed23d897b86ad316b64ad1ec9 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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) {
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (meminfo_read_failed(info))
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
sav_secs = cur_secs;
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
info->get_this.item = item;
// with 'get', we must NOT honor the usual 'noop' guarantee
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// if (item > MEMINFO_noop)
library: <MEMINFO> api, changed that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
info->get_this.result.ul_int = 0;
Item_table[item].setsfunc(&info->get_this, &info->hist);
return &info->get_this;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
} // end: procps_meminfo_get
library: meminfo redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains the following additional change without an API impact: . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
/* procps_meminfo_select():
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
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.
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*/
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
PROCPS_EXPORT struct meminfo_stack *procps_meminfo_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 meminfo_info *info,
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
enum meminfo_item *items,
int numitems)
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
{
if (info == NULL || items == NULL)
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (meminfo_items_check_failed(numitems, items))
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
/* is this the first time or have things changed since we were last called?
if so, gotta' redo all of our stacks stuff ... */
if (info->numitems != numitems + 1
|| memcmp(info->items, items, sizeof(enum meminfo_item) * numitems)) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// allow for our MEMINFO_logical_end
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (!(info->items = realloc(info->items, sizeof(enum meminfo_item) * (numitems + 1))))
library: minor fix for procps_meminfo_select Thus function returns a pointer, not an int, so if there is an error return NULL and not -errno. proc/meminfo.c: In function ‘procps_meminfo_select’: proc/meminfo.c:994:20: warning: return makes pointer from integer without a cast [-Wint-conversion] return -ENOMEM; References: commit 407f1b71de3c4baed23d897b86ad316b64ad1ec9
2016-05-12 03:22:36 +05:30
return NULL;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
memcpy(info->items, items, sizeof(enum meminfo_item) * numitems);
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
info->items[numitems] = MEMINFO_logical_end;
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
info->numitems = numitems + 1;
if (info->extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
meminfo_extents_free_all(info);
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
}
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (!info->extents
library: accumulated miscellaneous code/comment tweaks Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-24 23:42:12 +05:30
&& (!meminfo_stacks_alloc(info, 1)))
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
return NULL;
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
if (info->dirty_stacks)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
meminfo_cleanup_stacks_all(info);
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (meminfo_read_failed(info))
library: refactor meminfo providing dynamic allocation An earlier approach to meminfo chaining, referenced in the patch shown below, represents the first baby steps toward the goal of some generalized approach with PIDs processing. However, statically allocating a chain for each task or thread is totally impractical. And, while a single chain could serve all PIDs, that would mean a separate call to our library for each running process. This commit is intended as the next evolutionary step, dynamically allocating some 'result' chains to contain as many or as few 'items' as a caller wishes. In other words, holding only those 'items' of current interest. This is the kind of service useful for both top and ps programs if we finally get around to /proc/<PID> data. Reference(s): commit c3fd7473c5e2f8be59b2ac90696e79079f45b5a8 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
meminfo_assign_results(info->extents->stacks[0], &info->hist);
library: improve/normalize an interface, <MEMINFO> api This represents the refinement of this interface after the <stat> API was redesigned. We now follow a pattern of 'get' for single item retrieval & 'select' for when multiple items are desired, with just 1 function call. And again following the <stat> lead this interface now provides for delta values encompassing most items. The reason I went cuckoo nuts with those deltas is because they are essentially free. At the cost of a little RAM and just one memcpy there's no other price to be paid. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-11 22:30:00 +05:30
info->dirty_stacks = 1;
return info->extents->stacks[0];
} // end: procps_meminfo_select
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
// --- special debugging function(s) ------------------------------------------
/*
* The following isn't part of the normal programming interface. Rather,
* it exists to validate result types referenced in application programs.
*
* It's used only when:
* 1) the 'XTRA_PROCPS_DEBUG' has been defined, or
* 2) the '#include <proc/xtra-procps-debug.h>' used
*/
PROCPS_EXPORT struct meminfo_result *xtra_meminfo_get (
struct meminfo_info *info,
enum meminfo_item actual_enum,
const char *typestr,
const char *file,
int lineno)
{
struct meminfo_result *r = procps_meminfo_get(info, actual_enum);
library: ensure that all those 'GET' macros are robust When users call the native 'get' functions they have a responsibility to check that the result struct address was indeed returned. But when using those 'GET' macros there was no protection for possible NULL dereference. So this patch will add some protection for a potential failure of an underlying 'get' function. And should it occur then those 'GET' macros will just return a zero. Plus, we'll also mirror that behavior in the debugging header should the XTRA_PROCPS_DEBUG #define be active. And, we might as well add a warning when invalid items are passed to 'GET' macros, just like we do for 'VAL'. [ lastly, we added the missing opening parens/braces ] [ to 2 'GET' macros in that xtra-procps-debug.h file ] [ which went unnoticed until the qa folks caught up. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-06 21:41:11 +05:30
if (actual_enum < 0 || actual_enum >= MEMINFO_logical_end) {
fprintf(stderr, "%s line %d: invalid item = %d, type = %s\n"
, file, lineno, actual_enum, typestr);
}
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (r) {
char *str = Item_table[r->item].type2str;
if (str[0]
&& (strcmp(typestr, str)))
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
}
return r;
} // end: xtra_meminfo_get_
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
PROCPS_EXPORT struct meminfo_result *xtra_meminfo_val (
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
int relative_enum,
const char *typestr,
const struct meminfo_stack *stack,
struct meminfo_info *info,
const char *file,
int lineno)
{
char *str;
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
int i;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
for (i = 0; stack->head[i].item < MEMINFO_logical_end; i++)
;
if (relative_enum < 0 || relative_enum >= i) {
fprintf(stderr, "%s line %d: invalid relative_enum = %d, type = %s\n"
, file, lineno, relative_enum, typestr);
return NULL;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
}
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
str = Item_table[stack->head[relative_enum].item].type2str;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (str[0]
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
&& (strcmp(typestr, str))) {
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
}
return &stack->head[relative_enum];
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
} // end: xtra_meminfo_val
Reference in New Issue Copy Permalink