emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
5f2570c384
procps/proc/slabinfo.h

131 lines
4.0 KiB
C
Raw Normal View History

library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
/*
library: rename the 'slab' sources as 'slabinfo' files Where possible, libprocps files convey the name of the actual source pseudo file under the '/proc' directory. This patch brings slab into line with such a standard. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* slabinfo.h - slab related functions for libproc
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
* Copyright (C) 1998-2005 Albert Cahalan
* Copyright (C) 2015 Craig Small <csmall@enc.com.au>
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
* Copyright (C) 2016 Jim Warnerl <james.warner@comcast.net>
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
#ifndef _PROC_SLAB_H
#define _PROC_SLAB_H
library: cleanup of library includes The includes used to define a lot of things a library include should not. It was also a bit messy what was exposed in the library and what was not. get_pid_digits -> procps_pid_length and exported correctly MALLOC attribute move into relevant .c files NORETURN attribute moved to relevant .c, not used in library PURE attribute removed, it wasn't used KLONG/KLF/STRTOUKL were fixed for long, so now just use long HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT seems to do the same (opposite) thing. likely/unlikely removed from most places, its highly debateable this does anything useful as CPUs have gotten smarter about branches. Re-arranged the includes, ALL external programs should just #include <proc/procps.h> then proc/procps.h includes headers for files that have exported functions. procps.h and the headers it includes should not use items that are not exportable (e.g. hidden functions or macros) they go in procps-private.h
2016-04-16 12:33:57 +05:30
#include <features.h>
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
__BEGIN_DECLS
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item {
PROCPS_SLABINFO_noop, // n/a
PROCPS_SLABINFO_extra, // n/a
PROCPS_SLABS_OBJS, // u_int
PROCPS_SLABS_AOBJS, // u_int
PROCPS_SLABS_PAGES, // u_int
PROCPS_SLABS_SLABS, // u_int
PROCPS_SLABS_ASLABS, // u_int
PROCPS_SLABS_CACHES, // u_int
PROCPS_SLABS_ACACHES, // u_int
PROCPS_SLABS_SIZE_AVG, // u_int
PROCPS_SLABS_SIZE_MIN, // u_int
PROCPS_SLABS_SIZE_MAX, // u_int
PROCPS_SLABS_SIZE_ACTIVE, // ul_int
PROCPS_SLABS_SIZE_TOTAL, // ul_int
PROCPS_SLABS_DELTA_OBJS, // s_int
PROCPS_SLABS_DELTA_AOBJS, // s_int
PROCPS_SLABS_DELTA_PAGES, // s_int
PROCPS_SLABS_DELTA_SLABS, // s_int
PROCPS_SLABS_DELTA_ASLABS, // s_int
PROCPS_SLABS_DELTA_CACHES, // s_int
PROCPS_SLABS_DELTA_ACACHES, // s_int
PROCPS_SLABS_DELTA_SIZE_AVG, // s_int
PROCPS_SLABS_DELTA_SIZE_MIN, // s_int
PROCPS_SLABS_DELTA_SIZE_MAX, // s_int
PROCPS_SLABS_DELTA_SIZE_ACTIVE, // s_int
PROCPS_SLABS_DELTA_SIZE_TOTAL, // s_int
PROCPS_SLABNODE_NAME, // str
PROCPS_SLABNODE_OBJS, // u_int
PROCPS_SLABNODE_AOBJS, // u_int
PROCPS_SLABNODE_OBJ_SIZE, // u_int
PROCPS_SLABNODE_OBJS_PER_SLAB, // u_int
PROCPS_SLABNODE_PAGES_PER_SLAB, // u_int
PROCPS_SLABNODE_SLABS, // u_int
PROCPS_SLABNODE_ASLABS, // u_int
PROCPS_SLABNODE_USE, // u_int
PROCPS_SLABNODE_SIZE // ul_int
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_sort_order {
PROCPS_SLABINFO_ASCEND = +1,
PROCPS_SLABINFO_DESCEND = -1
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_result {
enum slabinfo_item item;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
union {
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
signed int s_int;
unsigned int u_int;
unsigned long ul_int;
char * str;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
} result;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
};
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_stack {
struct slabinfo_result *head;
};
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_reap {
int total;
struct slabinfo_stack **stacks;
};
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
#define PROCPS_SLABINFO_VAL(rel_enum,type,stack) \
stack -> head [ rel_enum ] . result . type
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct procps_slabinfo;
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
int procps_slabinfo_new (struct procps_slabinfo **info);
int procps_slabinfo_ref (struct procps_slabinfo *info);
int procps_slabinfo_unref (struct procps_slabinfo **info);
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
signed long procps_slabinfo_get (
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
struct procps_slabinfo *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item item);
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_reap *procps_slabinfo_reap (
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
struct procps_slabinfo *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item *items,
int numitems);
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_stack *procps_slabinfo_select (
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
struct procps_slabinfo *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item *items,
int numitems);
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_stack **procps_slabinfo_sort (
library: revised sort + new allocate APIs for slabinfo With this patch, we will be close to an implementation which will be needed when accommodating tasks/threads. The following explanation was from an earlier message: The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. ------------------------------------------------------ So this patch expands the API to provide dynamic chain allocation plus allow sorting of those dynamic chains. While specific to slab needs (nodes, not global stats) it is not too early to begin to think of newlib chains as the opaque replacement for a deprecated old proc_t. Better yet, any newlib chain is inherently variable in length, something the old proc_t couldn't claim to be. Of course, as we get to PIDs we'll want to grow/shrink chains (easily accomplished with a special item enum). And we'll want to grow/shrink those **head arrays too. But these minor details don't seem insurmountable now. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 10:30:00 +05:30
struct procps_slabinfo *info,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
struct slabinfo_stack *stacks[],
library: slab is 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 several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . 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
int numstacked,
library: normalize/standardize the i/f, <SLABINFO> api Before this major redesign, the slabs interface likely was our messiest 2nd generation attempt at opaqueness. Beyond the standard 'new', 'ref' & 'unref', there were a total of 12 exported functions. Now, there are four. The 1st step was to remove several of those functions. These were quick to go since they were not used (yet): . procps_slabnode_count . procps_slabnode_getname . procps_slabnode_getstack Then, the following were internalized so users needn't be burdened with implementation details in the future: . procps_slabinfo_read (renamed: read_slabinfo_failed) . procps_slabnode_stacks_alloc (renamed: stacks_alloc) Still others evolved into the minimal interface we had strived for in the other upgraded 3rd generation APIs: . procps_slabnode_get -----------> procps_slabinfo_get . separate stack_alloc/fill --> procps_slabinfo_select . separate stacks_alloc/fill ---> procps_slabinfo_reap . procps_slabnode_stacks_sort --> procps_slabinfo_sort ------------------------------------------------------ Beyond those reductions, the major modifications were: . This API tries to be as forgiving as possible and as such won't throw errors when a caller request makes no sense. For example, if a 'get' or 'select' requested a SLABNODE item (with no current means to id that node), results will be zero. By the same token, should 'reap' include a global SLABS item (meaning those values will be duplicated in *every* node stack) it'll be allowed. . If the above behavior is undesired, a new #define of ENFORCE_LOGICAL can be used to restrict certain items. . Permission problems will now be caught at 'new' time thanks to a priming 'read' call. That read also serves to make DELTA values potentially useful at 1st access. . Separate slab/slabnode enumerators were consolidated into one, simplifying validation & the results struct. . Several internal parameter checks were relaxed since they were already checked by the caller. Besides if we cannot trust our own code we might as well hang it up. . That sort provision was made more efficient and will offer the ascending choice, in addition to descending. ------------------------------------------------------ Lastly, some additional thoughts regarding the future: . It would not be difficult to expand 'select' to also accept a nodeid, or to clone it as 'select_node'. And, should the same be extended to 'get', a results struct could be returned instead of signed long accommodating the extra data type(s) like a node name (string data). . The 'get' function is not currently affected by that define ENFORCE_LOGICAL. However, at some future point perhaps -EINVAL would be more appropriate than a zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 10:30:00 +05:30
enum slabinfo_item sortitem,
enum slabinfo_sort_order order);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 10:29:59 +05:30
__END_DECLS
add slabtop, fix top ^Z terminal handling
2004-01-25 04:03:56 +05:30
#endif /* _PROC_SLAB_H */
Reference in New Issue Copy Permalink