emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
8a7fcc02d1
procps/proc/meminfo.h

161 lines
6.4 KiB
C
Raw Normal View History

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
* libprocps - Library to read proc filesystem
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
*
* 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: 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 procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 18:38:47 +05:30
#ifndef PROC_MEMINFO_H
#define PROC_MEMINFO_H
__BEGIN_DECLS
enum meminfo_item {
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_noop, // n/a ( never altered )
PROCPS_MEMINFO_extra, // n/a ( reset to zero )
/*
note: all of the following values are exressed as KiB
*/
PROCPS_MEMINFO_MEM_ACTIVE, // ul_int
PROCPS_MEMINFO_MEM_ACTIVE_ANON, // ul_int
PROCPS_MEMINFO_MEM_ACTIVE_FILE, // ul_int
PROCPS_MEMINFO_MEM_ANON, // ul_int
PROCPS_MEMINFO_MEM_AVAILABLE, // ul_int
PROCPS_MEMINFO_MEM_BOUNCE, // ul_int
PROCPS_MEMINFO_MEM_BUFFERS, // ul_int
PROCPS_MEMINFO_MEM_CACHED, // ul_int
PROCPS_MEMINFO_MEM_COMMIT_LIMIT, // ul_int
PROCPS_MEMINFO_MEM_COMMITTED_AS, // ul_int
PROCPS_MEMINFO_MEM_HARD_CORRUPTED, // ul_int
PROCPS_MEMINFO_MEM_DIRTY, // ul_int
PROCPS_MEMINFO_MEM_FREE, // ul_int
PROCPS_MEMINFO_MEM_HUGE_ANON, // ul_int
PROCPS_MEMINFO_MEM_HUGE_FREE, // ul_int
PROCPS_MEMINFO_MEM_HUGE_RSVD, // ul_int
PROCPS_MEMINFO_MEM_HUGE_SIZE, // ul_int
PROCPS_MEMINFO_MEM_HUGE_SURPLUS, // ul_int
PROCPS_MEMINFO_MEM_HUGE_TOTAL, // ul_int
PROCPS_MEMINFO_MEM_INACTIVE, // ul_int
PROCPS_MEMINFO_MEM_INACTIVE_ANON, // ul_int
PROCPS_MEMINFO_MEM_INACTIVE_FILE, // ul_int
PROCPS_MEMINFO_MEM_KERNEL_STACK, // ul_int
PROCPS_MEMINFO_MEM_LOCKED, // ul_int
PROCPS_MEMINFO_MEM_MAPPED, // ul_int
PROCPS_MEMINFO_MEM_NFS_UNSTABLE, // ul_int
PROCPS_MEMINFO_MEM_PAGE_TABLES, // ul_int
PROCPS_MEMINFO_MEM_SHARED, // ul_int
PROCPS_MEMINFO_MEM_SLAB, // ul_int
PROCPS_MEMINFO_MEM_SLAB_RECLAIM, // ul_int
PROCPS_MEMINFO_MEM_SLAB_UNRECLAIM, // ul_int
PROCPS_MEMINFO_MEM_TOTAL, // ul_int
PROCPS_MEMINFO_MEM_UNEVICTABLE, // ul_int
PROCPS_MEMINFO_MEM_USED, // ul_int
PROCPS_MEMINFO_MEM_VM_ALLOC_CHUNK, // ul_int
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
PROCPS_MEMINFO_MEM_VM_ALLOC_TOTAL, // 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
PROCPS_MEMINFO_MEM_VM_ALLOC_USED, // ul_int
PROCPS_MEMINFO_MEM_WRITEBACK, // ul_int
PROCPS_MEMINFO_MEM_WRITEBACK_TMP, // ul_int
PROCPS_MEMINFO_DELTA_ACTIVE, // s_int
PROCPS_MEMINFO_DELTA_ACTIVE_ANON, // s_int
PROCPS_MEMINFO_DELTA_ACTIVE_FILE, // s_int
PROCPS_MEMINFO_DELTA_ANON, // s_int
PROCPS_MEMINFO_DELTA_AVAILABLE, // s_int
PROCPS_MEMINFO_DELTA_BOUNCE, // s_int
PROCPS_MEMINFO_DELTA_BUFFERS, // s_int
PROCPS_MEMINFO_DELTA_CACHED, // s_int
PROCPS_MEMINFO_DELTA_COMMIT_LIMIT, // s_int
PROCPS_MEMINFO_DELTA_COMMITTED_AS, // s_int
PROCPS_MEMINFO_DELTA_HARD_CORRUPTED, // s_int
PROCPS_MEMINFO_DELTA_DIRTY, // s_int
PROCPS_MEMINFO_DELTA_FREE, // s_int
PROCPS_MEMINFO_DELTA_HUGE_ANON, // s_int
PROCPS_MEMINFO_DELTA_HUGE_FREE, // s_int
PROCPS_MEMINFO_DELTA_HUGE_RSVD, // s_int
PROCPS_MEMINFO_DELTA_HUGE_SIZE, // s_int
PROCPS_MEMINFO_DELTA_HUGE_SURPLUS, // s_int
PROCPS_MEMINFO_DELTA_HUGE_TOTAL, // s_int
PROCPS_MEMINFO_DELTA_INACTIVE, // s_int
PROCPS_MEMINFO_DELTA_INACTIVE_ANON, // s_int
PROCPS_MEMINFO_DELTA_INACTIVE_FILE, // s_int
PROCPS_MEMINFO_DELTA_KERNEL_STACK, // s_int
PROCPS_MEMINFO_DELTA_LOCKED, // s_int
PROCPS_MEMINFO_DELTA_MAPPED, // s_int
PROCPS_MEMINFO_DELTA_NFS_UNSTABLE, // s_int
PROCPS_MEMINFO_DELTA_PAGE_TABLES, // s_int
PROCPS_MEMINFO_DELTA_SHARED, // s_int
PROCPS_MEMINFO_DELTA_SLAB, // s_int
PROCPS_MEMINFO_DELTA_SLAB_RECLAIM, // s_int
PROCPS_MEMINFO_DELTA_SLAB_UNRECLAIM, // s_int
PROCPS_MEMINFO_DELTA_TOTAL, // s_int
PROCPS_MEMINFO_DELTA_UNEVICTABLE, // s_int
PROCPS_MEMINFO_DELTA_USED, // s_int
PROCPS_MEMINFO_DELTA_VM_ALLOC_CHUNK, // s_int
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
PROCPS_MEMINFO_DELTA_VM_ALLOC_TOTAL, // s_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
PROCPS_MEMINFO_DELTA_VM_ALLOC_USED, // s_int
PROCPS_MEMINFO_DELTA_WRITEBACK, // s_int
PROCPS_MEMINFO_DELTA_WRITEBACK_TMP, // s_int
PROCPS_MEMINFO_MEMHI_FREE, // ul_int
PROCPS_MEMINFO_MEMHI_TOTAL, // ul_int
PROCPS_MEMINFO_MEMHI_USED, // ul_int
PROCPS_MEMINFO_MEMLO_FREE, // ul_int
PROCPS_MEMINFO_MEMLO_TOTAL, // ul_int
PROCPS_MEMINFO_MEMLO_USED, // ul_int
PROCPS_MEMINFO_SWAP_CACHED, // ul_int
PROCPS_MEMINFO_SWAP_FREE, // ul_int
PROCPS_MEMINFO_SWAP_TOTAL, // ul_int
PROCPS_MEMINFO_SWAP_USED // ul_int
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: 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: 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
struct procps_meminfo;
library: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
struct meminfo_result {
enum meminfo_item item;
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
union {
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
signed int s_int;
unsigned long ul_int;
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
} result;
library: add chaining provisions to meminfo and vmstat If a caller chooses to reduce the overhead of repeated function calls, this commit provides for acquiring all the desired information in just a single library call. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
};
library: 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
struct meminfo_stack {
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
struct meminfo_result *head;
};
library: tweak formatting style for meminfo and vmstat This patch mostly just eliminates darn tab characters. Plus the library function declarations and definitions have been standardized. Most visibly, the input params now have all been indented on their own separate line. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: 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 PROCPS_MEMINFO_VAL(rel_enum,type,stack) \
stack -> head [ rel_enum ] . result . type
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
struct procps_meminfo;
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
int procps_meminfo_new (struct procps_meminfo **info);
int procps_meminfo_ref (struct procps_meminfo *info);
int procps_meminfo_unref (struct procps_meminfo **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
signed long procps_meminfo_get (
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
struct procps_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
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
struct meminfo_stack *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
struct procps_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
enum meminfo_item *items,
int numitems);
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
__END_DECLS
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
#endif
Reference in New Issue Copy Permalink