emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity
adfa2bc75a
procps/proc/stat.c

1021 lines
35 KiB
C
Raw Normal View History

library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
/*
* libprocps - Library to read proc filesystem
*
* 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: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#include <dlfcn.h>
library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include <stdlib.h>
#include <string.h>
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#include <time.h>
library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
#include <unistd.h>
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include <sys/stat.h>
library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
#include <sys/types.h>
library: rename those readstat.c & h sources to 'stat' In an attempt to normalize the 'stat' interface, we'll first shed any reminders of the old readproc interface by changing file names to be more descriptive & brief. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-25 10:30:00 +05:30
#include <proc/stat.h>
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#include <proc/sysinfo.h>
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#include "procps-private.h"
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
/* -------------------------------------------------------------------------
strictly development define(s), largely for the top program
( next has no affect if ./configure --disable-numa has been specified ) */
//#define PRETEND_NUMA // pretend there are 3 'discontiguous' nodes
// -------------------------------------------------------------------------
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
#define STAT_FILE "/proc/stat"
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#define STACKS_INCR 64 // amount reap stack allocations grow
#define NEWOLD_INCR 32 // amount jiffs hist allocations grow
struct stat_jifs {
unsigned long long user, nice, system, idle, iowait, irq, sirq, stolen, guest, gnice;
};
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
struct stat_data {
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
unsigned long intr;
unsigned long ctxt;
unsigned long btime;
unsigned long procs_created;
unsigned long procs_blocked;
unsigned long procs_running;
};
struct hist_sys {
struct stat_data new;
struct stat_data old;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
};
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct hist_tic {
int id;
int numa_node;
struct stat_jifs new;
struct stat_jifs old;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
};
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct stacks_extent {
int ext_numstacks;
struct stacks_extent *next;
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
struct stat_stack **stacks;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
};
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support {
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
int numitems; // includes 'logical_end' delimiter
enum stat_item *items; // includes 'logical_end' delimiter
struct stacks_extent *extents; // anchor for these extents
int dirty_stacks;
};
struct tic_support {
int n_alloc; // number of below structs allocated
int n_inuse; // number of below structs occupied
struct hist_tic *tics; // actual new/old jiffies
};
struct reap_support {
int total; // independently obtained # of cpus/nodes
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support fetch; // extents plus items details
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct tic_support hist; // cpu and node jiffies management
int n_anchor_alloc; // last known anchor pointers allocation
struct stat_stack **anchor; // reapable stacks (consolidated extents)
struct stat_reap result; // summary + stacks returned to caller
};
struct procps_statinfo {
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
int refcount;
int stat_fd;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
int stat_was_read; // is stat file history valid?
struct hist_sys sys_hist; // SYS type management
struct hist_tic cpu_hist; // TIC type management for cpu summary
struct reap_support cpus; // TIC type management for real cpus
struct reap_support nodes; // TIC type management for numa nodes
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support cpu_summary; // supports /proc/stat line #1 results
struct ext_support select; // support for 'procps_stat_select()'
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct stat_reaped results; // for return to caller after a reap
#ifndef NUMA_DISABLE
void *libnuma_handle; // if dlopen() for libnuma succeessful
int (*our_max_node)(void); // a libnuma function call via dlsym()
int (*our_node_of_cpu)(int); // a libnuma function call via dlsym()
#endif
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
};
library: tweak formatting for readstat header and code 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. The following names were changed to more closely match meminfo.c or provide a certain symmetry. Unfortunately that also impacted some other pgms which were updated. . 'procps_stat_get' evolved into 'procps_stat_get_sys' . 'procps_stat_info' is now known as 'procps_statinfo' [and just a little trailing whitespace was eliminated] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// ___ Results 'Set' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
#define setNAME(e) set_results_ ## e
#define setDECL(e) static void setNAME(e) \
(struct stat_result *R, struct hist_sys *S, struct hist_tic *T)
// regular assignment
#define TIC_set(e,t,x) setDECL(e) { \
(void)S; R->result. t = T->new . x; }
#define SYS_set(e,t,x) setDECL(e) { \
(void)T; R->result. t = S->new . x; }
// delta assignment
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
#define TICsetH(e,t,x) setDECL(e) { \
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
(void)S; R->result. t = ( T->new . x - T->old. x ); \
if (R->result. t < 0) R->result. t = 0; }
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
#define SYSsetH(e,t,x) setDECL(e) { \
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
(void)T; R->result. t = ( S->new . x - S->old. x ); \
if (R->result. t < 0) R->result. t = 0; }
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
setDECL(noop) { (void)R; (void)S; (void)T; }
setDECL(extra) { (void)R; (void)S; (void)T; }
setDECL(TIC_ID) { (void)S; R->result.s_int = T->id; }
setDECL(TIC_NUMA_NODE) { (void)S; R->result.s_int = T->numa_node; }
TIC_set(TIC_USER, ull_int, user)
TIC_set(TIC_NICE, ull_int, nice)
TIC_set(TIC_SYSTEM, ull_int, system)
TIC_set(TIC_IDLE, ull_int, idle)
TIC_set(TIC_IOWAIT, ull_int, iowait)
TIC_set(TIC_IRQ, ull_int, irq)
TIC_set(TIC_SOFTIRQ, ull_int, sirq)
TIC_set(TIC_STOLEN, ull_int, stolen)
TIC_set(TIC_GUEST, ull_int, guest)
TIC_set(TIC_GUEST_NICE, ull_int, gnice)
TICsetH(TIC_DELTA_USER, sl_int, user)
TICsetH(TIC_DELTA_NICE, sl_int, nice)
TICsetH(TIC_DELTA_SYSTEM, sl_int, system)
TICsetH(TIC_DELTA_IDLE, sl_int, idle)
TICsetH(TIC_DELTA_IOWAIT, sl_int, iowait)
TICsetH(TIC_DELTA_IRQ, sl_int, irq)
TICsetH(TIC_DELTA_SOFTIRQ, sl_int, sirq)
TICsetH(TIC_DELTA_STOLEN, sl_int, stolen)
TICsetH(TIC_DELTA_GUEST, sl_int, guest)
TICsetH(TIC_DELTA_GUEST_NICE, sl_int, gnice)
SYS_set(SYS_CTX_SWITCHES, ul_int, ctxt)
SYS_set(SYS_INTERRUPTS, ul_int, intr)
SYS_set(SYS_PROC_BLOCKED, ul_int, procs_blocked)
SYS_set(SYS_PROC_CREATED, ul_int, procs_created)
SYS_set(SYS_PROC_RUNNING, ul_int, procs_running)
SYS_set(SYS_TIME_OF_BOOT, ul_int, btime)
SYSsetH(SYS_DELTA_CTX_SWITCHES, s_int, ctxt)
SYSsetH(SYS_DELTA_INTERRUPTS, s_int, intr)
setDECL(SYS_DELTA_PROC_BLOCKED) { (void)T; R->result.s_int = S->new.procs_blocked - S->old.procs_blocked; }
SYSsetH(SYS_DELTA_PROC_CREATED, s_int, procs_created)
setDECL(SYS_DELTA_PROC_RUNNING) { (void)T; R->result.s_int = S->new.procs_running - S->old.procs_running; }
// ___ Results 'Get' Support ||||||||||||||||||||||||||||||||||||||||||||||||||
#define getNAME(e) get_results_ ## e
#define getDECL(e) static signed long getNAME(e) \
(struct procps_statinfo *I)
// regular get
#define TIC_get(e,x) getDECL(e) { return I->cpu_hist.new . x; }
#define SYS_get(e,x) getDECL(e) { return I->sys_hist.new . x; }
// delta get
#define TICgetH(e,x) getDECL(e) { \
long long n = I->cpu_hist.new. x - I->cpu_hist.old. x; \
return n < 0 ? 0 : n; }
#define SYSgetH(e,x) getDECL(e) { \
long long n = I->sys_hist.new. x - I->sys_hist.old. x; \
return n < 0 ? 0 : n; }
getDECL(noop) { (void)I; return 0; }
getDECL(extra) { (void)I; return 0; }
getDECL(TIC_ID) { return I->cpu_hist.id; }
getDECL(TIC_NUMA_NODE) { return I->cpu_hist.numa_node; }
TIC_get(TIC_USER, user)
TIC_get(TIC_NICE, nice)
TIC_get(TIC_SYSTEM, system)
TIC_get(TIC_IDLE, idle)
TIC_get(TIC_IOWAIT, iowait)
TIC_get(TIC_IRQ, irq)
TIC_get(TIC_SOFTIRQ, sirq)
TIC_get(TIC_STOLEN, stolen)
TIC_get(TIC_GUEST, guest)
TIC_get(TIC_GUEST_NICE, gnice)
TICgetH(TIC_DELTA_USER, user)
TICgetH(TIC_DELTA_NICE, nice)
TICgetH(TIC_DELTA_SYSTEM, system)
TICgetH(TIC_DELTA_IDLE, idle)
TICgetH(TIC_DELTA_IOWAIT, iowait)
TICgetH(TIC_DELTA_IRQ, irq)
TICgetH(TIC_DELTA_SOFTIRQ, sirq)
TICgetH(TIC_DELTA_STOLEN, stolen)
TICgetH(TIC_DELTA_GUEST, guest)
TICgetH(TIC_DELTA_GUEST_NICE, gnice)
SYS_get(SYS_CTX_SWITCHES, ctxt)
SYS_get(SYS_INTERRUPTS, intr)
SYS_get(SYS_PROC_BLOCKED, procs_blocked)
SYS_get(SYS_PROC_CREATED, procs_created)
SYS_get(SYS_PROC_RUNNING, procs_running)
SYS_get(SYS_TIME_OF_BOOT, btime)
SYSgetH(SYS_DELTA_CTX_SWITCHES, ctxt)
SYSgetH(SYS_DELTA_INTERRUPTS, intr)
getDECL(SYS_DELTA_PROC_BLOCKED) { return I->sys_hist.new.procs_blocked - I->sys_hist.old.procs_blocked; }
SYSgetH(SYS_DELTA_PROC_CREATED, procs_created)
getDECL(SYS_DELTA_PROC_RUNNING) { return I->sys_hist.new.procs_running - I->sys_hist.old.procs_running; }
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
// ___ Controlling Table ||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
typedef void (*SET_t)(struct stat_result *, struct hist_sys *, struct hist_tic *);
#define RS(e) (SET_t)setNAME(e)
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
typedef long long (*GET_t)(struct procps_statinfo *);
#define RG(e) (GET_t)getNAME(e)
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
/*
* Need it be said?
* This table must be kept in the exact same order as
* those 'enum stat_item' guys ! */
static struct {
SET_t setsfunc; // the actual result setting routine
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
GET_t getsfunc; // a routine to return single result
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
} Item_table[] = {
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
/* setsfunc getsfunc
--------------------------- ------------------------- */
{ RS(noop), RG(noop) },
{ RS(extra), RG(extra) },
{ RS(TIC_ID), RG(TIC_ID) },
{ RS(TIC_NUMA_NODE), RG(TIC_NUMA_NODE) },
{ RS(TIC_USER), RG(TIC_USER) },
{ RS(TIC_NICE), RG(TIC_NICE) },
{ RS(TIC_SYSTEM), RG(TIC_SYSTEM) },
{ RS(TIC_IDLE), RG(TIC_IDLE) },
{ RS(TIC_IOWAIT), RG(TIC_IOWAIT) },
{ RS(TIC_IRQ), RG(TIC_IRQ) },
{ RS(TIC_SOFTIRQ), RG(TIC_SOFTIRQ) },
{ RS(TIC_STOLEN), RG(TIC_STOLEN) },
{ RS(TIC_GUEST), RG(TIC_GUEST) },
{ RS(TIC_GUEST_NICE), RG(TIC_GUEST_NICE) },
{ RS(TIC_DELTA_USER), RG(TIC_DELTA_USER) },
{ RS(TIC_DELTA_NICE), RG(TIC_DELTA_NICE) },
{ RS(TIC_DELTA_SYSTEM), RG(TIC_DELTA_SYSTEM) },
{ RS(TIC_DELTA_IDLE), RG(TIC_DELTA_IDLE) },
{ RS(TIC_DELTA_IOWAIT), RG(TIC_DELTA_IOWAIT) },
{ RS(TIC_DELTA_IRQ), RG(TIC_DELTA_IRQ) },
{ RS(TIC_DELTA_SOFTIRQ), RG(TIC_DELTA_SOFTIRQ) },
{ RS(TIC_DELTA_STOLEN), RG(TIC_DELTA_STOLEN) },
{ RS(TIC_DELTA_GUEST), RG(TIC_DELTA_GUEST) },
{ RS(TIC_DELTA_GUEST_NICE), RG(TIC_DELTA_GUEST_NICE) },
{ RS(SYS_CTX_SWITCHES), RG(SYS_CTX_SWITCHES) },
{ RS(SYS_INTERRUPTS), RG(SYS_INTERRUPTS) },
{ RS(SYS_PROC_BLOCKED), RG(SYS_PROC_BLOCKED) },
{ RS(SYS_PROC_CREATED), RG(SYS_PROC_CREATED) },
{ RS(SYS_PROC_RUNNING), RG(SYS_PROC_RUNNING) },
{ RS(SYS_TIME_OF_BOOT), RG(SYS_TIME_OF_BOOT) },
{ RS(SYS_DELTA_CTX_SWITCHES), RG(SYS_DELTA_CTX_SWITCHES) },
{ RS(SYS_DELTA_INTERRUPTS), RG(SYS_DELTA_INTERRUPTS) },
{ RS(SYS_DELTA_PROC_BLOCKED), RG(SYS_DELTA_PROC_BLOCKED) },
{ RS(SYS_DELTA_PROC_CREATED), RG(SYS_DELTA_PROC_CREATED) },
{ RS(SYS_DELTA_PROC_RUNNING), RG(SYS_DELTA_PROC_RUNNING) },
{ NULL, NULL }
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
};
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
/* please note,
* 1st enum MUST be kept in sync with highest TIC type
* 2nd enum MUST be 1 greater than the highest value of any enum */
enum stat_item PROCPS_STAT_TIC_highest = PROCPS_STAT_TIC_DELTA_GUEST_NICE;
enum stat_item PROCPS_STAT_logical_end = PROCPS_STAT_SYS_DELTA_PROC_RUNNING + 1;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
#undef setNAME
#undef setDECL
#undef TIC_set
#undef SYS_set
#undef TICsetH
#undef SYSsetH
#undef getNAME
#undef getDECL
#undef TIC_get
#undef SYS_get
#undef TICgetH
#undef SYSgetH
#undef RS
#undef RG
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// ___ Private Functions ||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#ifndef NUMA_DISABLE
#ifdef PRETEND_NUMA
static int fake_max_node (void) { return 3; }
static int fake_node_of_cpu (int n) { return (1 == (n % 4)) ? 0 : (n % 4); }
#endif
#endif
static inline void assign_results (
struct stat_stack *stack,
struct hist_sys *sys_hist,
struct hist_tic *tic_hist)
{
struct stat_result *this = stack->head;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: make reads & unref logic a little more robust Since we are not using a higher level standard C fopen all of the read requests were made signal sensitive as that can result in a 'temporarily' failed i/o request. Also, protection against some user calling the 'unref' function on already free memory has been incorporated. This will protect us from some nasty 'Abort' surprise. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
for (;;) {
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
enum stat_item item = this->item;
if (item >= PROCPS_STAT_logical_end)
break;
Item_table[item].setsfunc(this, sys_hist, tic_hist);
++this;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
return;
} // end: assign_results
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static inline void cleanup_stack (
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
struct stat_result *this)
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
{
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
for (;;) {
if (this->item >= PROCPS_STAT_logical_end)
library: tweak formatting for readstat header and code 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. The following names were changed to more closely match meminfo.c or provide a certain symmetry. Unfortunately that also impacted some other pgms which were updated. . 'procps_stat_get' evolved into 'procps_stat_get_sys' . 'procps_stat_info' is now known as 'procps_statinfo' [and just a little trailing whitespace was eliminated] Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
break;
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
if (this->item > PROCPS_STAT_noop)
this->result.ull_int = 0;
++this;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
}
} // end: cleanup_stack
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static inline void cleanup_stacks_all (
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support *this)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct stacks_extent *ext = this->extents;
int i;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
while (ext) {
for (i = 0; ext->stacks[i]; i++)
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
cleanup_stack(ext->stacks[i]->head);
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
ext = ext->next;
};
this->dirty_stacks = 0;
} // end: cleanup_stacks_all
static void extents_free_all (
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support *this)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
do {
struct stacks_extent *p = this->extents;
this->extents = this->extents->next;
free(p);
} while (this->extents);
} // end: extents_free_all
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static inline struct stat_result *itemize_stack (
struct stat_result *p,
int depth,
enum stat_item *items)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct stat_result *p_sav = p;
int i;
for (i = 0; i < depth; i++) {
p->item = items[i];
p->result.ull_int = 0;
++p;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
return p_sav;
} // end: itemize_stack
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static inline int items_check_failed (
int numitems,
enum stat_item *items)
library: add chaining provisions to readstat cpu & sys 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: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
int i;
library: add chaining provisions to readstat cpu & sys 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: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
/* if an enum is passed instead of an address of one or more enums, ol' gcc
* will silently convert it to an address (possibly NULL). only clang will
* offer any sort of warning like the following:
*
* warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'enum stat_item *'
* my_stack = procps_stat_select(info, PROCPS_STAT_noop, num);
* ^~~~~~~~~~~~~~~~
*/
if (numitems < 1
|| (void *)items < (void *)(unsigned long)(2 * PROCPS_STAT_logical_end))
return -1;
for (i = 0; i < numitems; i++) {
// a stat_item is currently unsigned, but we'll protect our future
if (items[i] < 0)
return -1;
if (items[i] >= PROCPS_STAT_logical_end) {
return -1;
library: add chaining provisions to readstat cpu & sys 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: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
return 0;
} // end: items_check_failed
library: add chaining provisions to readstat cpu & sys 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: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static int make_numa_hist (
struct procps_statinfo *info)
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#ifndef NUMA_DISABLE
struct hist_tic *cpu_ptr, *nod_ptr;
int i, node;
if (info->libnuma_handle == NULL
|| (!info->nodes.total)) {
return 0;
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 03:13:02 +05:30
}
library: add chaining provisions to readstat cpu & sys 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: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
/* are numa nodes dynamic like online cpus can be?
( and be careful, this libnuma call returns the highest node id in use, )
( NOT an actual number of nodes - some of those 'slots' might be unused ) */
info->nodes.total = info->our_max_node() + 1;
if (!info->nodes.hist.n_alloc
|| !(info->nodes.total < info->nodes.hist.n_alloc)) {
info->nodes.hist.n_alloc = info->nodes.total + NEWOLD_INCR;
info->nodes.hist.tics = realloc(info->nodes.hist.tics, info->nodes.hist.n_alloc * sizeof(struct hist_tic));
if (!(info->nodes.hist.tics))
return -ENOMEM;
}
library: add chaining provisions to readstat cpu & sys 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: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// forget all of the prior node statistics & anticipate unassigned slots
memset(info->nodes.hist.tics, 0, info->nodes.hist.n_alloc * sizeof(struct hist_tic));
nod_ptr = info->nodes.hist.tics;
for (i = 0; i < info->cpus.hist.n_alloc; i++) {
nod_ptr->id = nod_ptr->numa_node = PROCPS_STAT_NODE_INVALID;
++nod_ptr;
}
// spin thru each cpu and value the jiffs for it's numa node
for (i = 0; i < info->cpus.hist.n_inuse; i++) {
cpu_ptr = info->cpus.hist.tics + i;
if (-1 < (node = info->our_node_of_cpu(cpu_ptr->id))) {
nod_ptr = info->nodes.hist.tics + node;
nod_ptr->new.user += cpu_ptr->new.user; nod_ptr->old.user += cpu_ptr->old.user;
nod_ptr->new.nice += cpu_ptr->new.nice; nod_ptr->old.nice += cpu_ptr->old.nice;
nod_ptr->new.system += cpu_ptr->new.system; nod_ptr->old.system += cpu_ptr->old.system;
nod_ptr->new.idle += cpu_ptr->new.idle; nod_ptr->old.idle += cpu_ptr->old.idle;
nod_ptr->new.iowait += cpu_ptr->new.iowait; nod_ptr->old.iowait += cpu_ptr->old.iowait;
nod_ptr->new.irq += cpu_ptr->new.irq; nod_ptr->old.irq += cpu_ptr->old.irq;
nod_ptr->new.sirq += cpu_ptr->new.sirq; nod_ptr->old.sirq += cpu_ptr->old.sirq;
nod_ptr->new.stolen += cpu_ptr->new.stolen; nod_ptr->old.stolen += cpu_ptr->old.stolen;
/*
* note: the above call to 'our_node_of_cpu' will produce a modest
* memory leak summarized as:
* ==1234== LEAK SUMMARY:
* ==1234== definitely lost: 512 bytes in 1 blocks
* ==1234== indirectly lost: 48 bytes in 2 blocks
* ==1234== ...
* [ thanks very much libnuma, for all the pain you've caused us ]
*/
cpu_ptr->numa_node = node;
nod_ptr->id = node;
library: add chaining provisions to readstat cpu & sys 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: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
info->nodes.hist.n_inuse = info->nodes.total;
return info->nodes.hist.n_inuse;
#else
return 0;
#endif
} // end: make_numa_hist
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static int read_stat_failed (
struct procps_statinfo *info)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct hist_tic *sum_ptr, *cpu_ptr;
char buf[8192], *bp, *b;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
int i, rc, size;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
unsigned long long llnum = 0;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
if (info == NULL)
return -EINVAL;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (!info->cpus.hist.n_alloc) {
info->cpus.hist.tics = calloc(NEWOLD_INCR, sizeof(struct hist_tic));
if (!(info->cpus.hist.tics))
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return -ENOMEM;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
info->cpus.hist.n_alloc = NEWOLD_INCR;
info->cpus.hist.n_inuse = 0;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
if (-1 == info->stat_fd && (info->stat_fd = open(STAT_FILE, O_RDONLY)) == -1)
return -errno;
if (lseek(info->stat_fd, 0L, SEEK_SET) == -1)
return -errno;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
for (;;) {
if ((size = read(info->stat_fd, buf, sizeof(buf)-1)) < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return -errno;
}
break;
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (size == 0) {
return -EIO;
}
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
buf[size] = '\0';
bp = buf;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
sum_ptr = &info->cpu_hist;
// remember summary from last time around
memcpy(&sum_ptr->old, &sum_ptr->new, sizeof(struct stat_jifs));
sum_ptr->id = PROCPS_STAT_SUMMARY_ID; // mark as summary
sum_ptr->numa_node = PROCPS_STAT_NODE_INVALID; // mark as invalid
// now value the cpu summary tics from line #1
Replace %Lu with standard %llu Multiple scanf()s use the GNU-permitted %Lu. This is not supported in other libraries and isn't to the POSIX specification. The L modifier is only used for floats in POSIX. Replacing %Lu with %llu is the same for GNU libc (scanf(3) says as much) but means other libraries will work fine. From master commit da715e3 References: http://pubs.opengroup.org/onlinepubs/009695399/functions/fscanf.html
2016-04-14 16:51:27 +05:30
if (8 > sscanf(bp, "cpu %llu %llu %llu %llu %llu %llu %llu %llu %llu %llu"
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
, &sum_ptr->new.user, &sum_ptr->new.nice, &sum_ptr->new.system
, &sum_ptr->new.idle, &sum_ptr->new.iowait, &sum_ptr->new.irq
, &sum_ptr->new.sirq, &sum_ptr->new.stolen
, &sum_ptr->new.guest, &sum_ptr->new.gnice))
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return -1;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// let's not distort the deltas the first time thru ...
if (!info->stat_was_read)
memcpy(&sum_ptr->old, &sum_ptr->new, sizeof(struct stat_jifs));
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
i = 0;
reap_em_again:
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
cpu_ptr = info->cpus.hist.tics + i; // adapt to relocated if reap_em_again
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
do {
bp = 1 + strchr(bp, '\n');
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// remember this cpu from last time around
memcpy(&cpu_ptr->old, &cpu_ptr->new, sizeof(struct stat_jifs));
// next can be overridden under 'make_numa_hist'
cpu_ptr->numa_node = PROCPS_STAT_NODE_INVALID;
Replace %Lu with standard %llu Multiple scanf()s use the GNU-permitted %Lu. This is not supported in other libraries and isn't to the POSIX specification. The L modifier is only used for floats in POSIX. Replacing %Lu with %llu is the same for GNU libc (scanf(3) says as much) but means other libraries will work fine. From master commit da715e3 References: http://pubs.opengroup.org/onlinepubs/009695399/functions/fscanf.html
2016-04-14 16:51:27 +05:30
if (8 > (rc = sscanf(bp, "cpu%d %llu %llu %llu %llu %llu %llu %llu %llu %llu %llu"
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
, &cpu_ptr->id
, &cpu_ptr->new.user, &cpu_ptr->new.nice, &cpu_ptr->new.system
, &cpu_ptr->new.idle, &cpu_ptr->new.iowait, &cpu_ptr->new.irq
, &cpu_ptr->new.sirq, &cpu_ptr->new.stolen
, &cpu_ptr->new.guest, &cpu_ptr->new.gnice))) {
int id_sav = cpu_ptr->id;
memmove(cpu_ptr, sum_ptr, sizeof(struct hist_tic));
cpu_ptr->id = id_sav;
break; // we must tolerate cpus taken offline
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// let's not distort the deltas the first time thru ...
if (!info->stat_was_read)
memcpy(&cpu_ptr->old, &cpu_ptr->new, sizeof(struct stat_jifs));
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
++i;
++cpu_ptr;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
} while (i < info->cpus.hist.n_alloc);
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (i == info->cpus.hist.n_alloc && rc >= 8) {
info->cpus.hist.n_alloc += NEWOLD_INCR;
info->cpus.hist.tics = realloc(info->cpus.hist.tics, info->cpus.hist.n_alloc * sizeof(struct hist_tic));
if (!(info->cpus.hist.tics))
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return -ENOMEM;
goto reap_em_again;
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
info->cpus.total = info->cpus.hist.n_inuse = i;
// remember sys_hist stuff from last time around
memcpy(&info->sys_hist.old, &info->sys_hist.new, sizeof(struct stat_data));
llnum = 0;
b = strstr(bp, "intr ");
if(b) sscanf(b, "intr %llu", &llnum);
info->sys_hist.new.intr = llnum;
llnum = 0;
b = strstr(bp, "ctxt ");
if(b) sscanf(b, "ctxt %llu", &llnum);
info->sys_hist.new.ctxt = llnum;
llnum = 0;
b = strstr(bp, "btime ");
if(b) sscanf(b, "btime %llu", &llnum);
info->sys_hist.new.btime = llnum;
llnum = 0;
b = strstr(bp, "processes ");
if(b) sscanf(b, "processes %llu", &llnum);
info->sys_hist.new.procs_created = llnum;
llnum = 0;
b = strstr(bp, "procs_blocked ");
if(b) sscanf(b, "procs_blocked %llu", &llnum);
info->sys_hist.new.procs_blocked = llnum;
llnum = 0;
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
b = strstr(bp, "procs_running ");
if(b) sscanf(b, "procs_running %llu", &llnum);
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
info->sys_hist.new.procs_running = llnum;
// let's not distort the deltas the first time thru ...
if (!info->stat_was_read)
memcpy(&info->sys_hist.old, &info->sys_hist.new, sizeof(struct stat_data));
info->stat_was_read = 1;
return 0;
} // end: read_stat_failed
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
/*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* stacks_alloc():
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* Allocate and initialize one or more stacks each of which is anchored in an
* associated stat_stack structure.
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* All such stacks will have their result structures properly primed with
* 'items', while the result itself will be zeroed.
*
* Returns a stack_extent struct anchoring the 'heads' of each new stack.
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*/
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
static struct stacks_extent *stacks_alloc (
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support *this,
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
int maxstacks)
{
struct stacks_extent *p_blob;
struct stat_stack **p_vect;
struct stat_stack *p_head;
size_t vect_size, head_size, list_size, blob_size;
void *v_head, *v_list;
int i;
if (this == NULL || this->items == NULL)
return NULL;
if (maxstacks < 1)
return NULL;
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
vect_size = sizeof(void *) * maxstacks; // size of the addr vectors |
vect_size += sizeof(void *); // plus NULL addr delimiter |
head_size = sizeof(struct stat_stack); // size of that head struct |
list_size = sizeof(struct stat_result) * this->numitems; // any single results stack |
blob_size = sizeof(struct stacks_extent); // the extent anchor itself |
blob_size += vect_size; // plus room for addr vects |
blob_size += head_size * maxstacks; // plus room for head thing |
blob_size += list_size * maxstacks; // plus room for our stacks |
/* note: all of our memory is allocated in a single blob, facilitating a later free(). |
as a minimum, it is important that the result structures themselves always be |
contiguous for every stack since they are accessed through relative position. | */
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (NULL == (p_blob = calloc(1, blob_size)))
return NULL;
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
p_blob->next = this->extents; // push this extent onto... |
this->extents = p_blob; // ...some existing extents |
p_vect = (void *)p_blob + sizeof(struct stacks_extent); // prime our vector pointer |
p_blob->stacks = p_vect; // set actual vectors start |
v_head = (void *)p_vect + vect_size; // prime head pointer start |
v_list = v_head + (head_size * maxstacks); // prime our stacks pointer |
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
for (i = 0; i < maxstacks; i++) {
p_head = (struct stat_stack *)v_head;
p_head->head = itemize_stack((struct stat_result *)v_list, this->numitems, this->items);
p_blob->stacks[i] = p_head;
v_list += list_size;
v_head += head_size;
}
p_blob->ext_numstacks = maxstacks;
return p_blob;
} // end: stacks_alloc
static int stacks_fetch_tics (
struct procps_statinfo *info,
struct reap_support *this)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct stacks_extent *ext;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
int i;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (this == NULL)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return -EINVAL;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// initialize stuff -----------------------------------
if (!this->anchor) {
if (!(this->anchor = calloc(sizeof(void *), STACKS_INCR)))
return -ENOMEM;
this->n_anchor_alloc = STACKS_INCR;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (!this->fetch.extents) {
if (!(ext = stacks_alloc(&this->fetch, this->n_anchor_alloc)))
return -ENOMEM;
memcpy(this->anchor, ext->stacks, sizeof(void *) * this->n_anchor_alloc);
}
if (this->fetch.dirty_stacks)
cleanup_stacks_all(&this->fetch);
// iterate stuff --------------------------------------
for (i = 0; i < this->hist.n_inuse; i++) {
if (!(i < this->n_anchor_alloc)) {
this->n_anchor_alloc += STACKS_INCR;
if ((!(this->anchor = realloc(this->anchor, sizeof(void *) * this->n_anchor_alloc)))
|| (!(ext = stacks_alloc(&this->fetch, STACKS_INCR)))) {
return -ENOMEM;
}
memcpy(this->anchor + i, ext->stacks, sizeof(void *) * STACKS_INCR);
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
assign_results(this->anchor[i], &info->sys_hist, &this->hist.tics[i]);
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
// finalize stuff -------------------------------------
this->result.total = i;
this->result.stacks = this->anchor;
this->fetch.dirty_stacks = 1;
return this->result.total;
} // end: stacks_fetch_tics
static int stacks_reconfig_maybe (
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support *this,
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
enum stat_item *items,
int numitems)
{
if (items_check_failed(numitems, items))
return -EINVAL;
/* is this the first time or have things changed since we were last called?
if so, gotta' redo all of our stacks stuff ... */
if (this->numitems != numitems + 1
|| memcmp(this->items, items, sizeof(enum stat_item) * numitems)) {
// allow for our PROCPS_STAT_logical_end
if (!(this->items = realloc(this->items, sizeof(enum stat_item) * (numitems + 1))))
return -ENOMEM;
memcpy(this->items, items, sizeof(enum stat_item) * numitems);
this->items[numitems] = PROCPS_STAT_logical_end;
this->numitems = numitems + 1;
if (this->extents)
extents_free_all(this);
return 1;
}
return 0;
} // end: stacks_reconfig_maybe
static struct stat_stack *update_single_stack (
struct procps_statinfo *info,
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
struct ext_support *this,
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
enum stat_item *items,
int numitems)
{
if (0 > stacks_reconfig_maybe(this, items, numitems))
return NULL;
if (!this->extents
library: make struct name more descriptive, <STAT> api After normalizing the <SLABINFO> module, much of which was based on this module, a structure which is crucial to concurrent select/reap support is renamed the same. Such a need for concurrent support was revealed during slabtop testing. That program requests (select) global data after calling for individual node data (reap) but before those stacks have been accessed. Therefore, one set of 'items'/'extents' could not possibly be shared. So now we will know the former struct fetch_support as ext_support. The former name was potentially confusing since the struct was used by both 'select' and 'reap'. However, only 'reap' ever called the 'fetch' function. [ this <STAT> already accommodated concurrent usage. ] [ in fact it contains 3 separate sets of items/exts. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-06 10:30:00 +05:30
&& !(stacks_alloc(this, 1)))
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
return NULL;
if (this->dirty_stacks)
cleanup_stacks_all(this);
assign_results(this->extents->stacks[0], &info->sys_hist, &info->cpu_hist);
this->dirty_stacks = 1;
return this->extents->stacks[0];
} // end: update_single_stack
#if defined(PRETEND_NUMA) && defined(NUMA_DISABLE)
# warning 'PRETEND_NUMA' ignored, 'NUMA_DISABLE' is active
#endif
// ___ Public Functions |||||||||||||||||||||||||||||||||||||||||||||||||||||||
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
/*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* procps_stat_new:
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* Create a new container to hold the stat information
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* The initial refcount is 1, and needs to be decremented
* to release the resources of the structure.
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* Returns: a new stat info container
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*/
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
PROCPS_EXPORT int procps_stat_new (
struct procps_statinfo **info)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
struct procps_statinfo *p;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (info == NULL || *info != NULL)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return -EINVAL;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (!(p = calloc(1, sizeof(struct procps_statinfo))))
return -ENOMEM;
library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
p->refcount = 1;
p->stat_fd = -1;
p->results.cpus = &p->cpus.result;
p->results.nodes = &p->nodes.result;
p->cpus.total = procps_cpu_count();
#ifndef NUMA_DISABLE
#ifndef PRETEND_NUMA
// we'll try for the most recent version, then a version we know works...
if ((p->libnuma_handle = dlopen("libnuma.so", RTLD_LAZY))
|| (p->libnuma_handle = dlopen("libnuma.so.1", RTLD_LAZY))) {
p->our_max_node = dlsym(p->libnuma_handle, "numa_max_node");
p->our_node_of_cpu = dlsym(p->libnuma_handle, "numa_node_of_cpu");
if (p->our_max_node && p->our_node_of_cpu)
p->nodes.total = p->our_max_node() + 1;
else {
dlclose(p->libnuma_handle);
p->libnuma_handle = NULL;
}
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
#else
p->libnuma_handle = (void *)-1;
p->our_max_node = fake_max_node;
p->our_node_of_cpu = fake_node_of_cpu;
p->nodes.total = fake_max_node() + 1;
#endif
#endif
*info = p;
return 0;
} // end :procps_stat_new
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
PROCPS_EXPORT int procps_stat_ref (
struct procps_statinfo *info)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
{
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (info == NULL)
return -EINVAL;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
info->refcount++;
return info->refcount;
} // end: procps_stat_ref
PROCPS_EXPORT int procps_stat_unref (
struct procps_statinfo **info)
{
if (info == NULL || *info == NULL)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return -EINVAL;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
(*info)->refcount--;
if ((*info)->refcount == 0) {
if ((*info)->cpus.anchor)
free((*info)->cpus.anchor);
if ((*info)->cpus.hist.tics)
free((*info)->cpus.hist.tics);
if ((*info)->cpus.fetch.items)
free((*info)->cpus.fetch.items);
if ((*info)->cpus.fetch.extents)
extents_free_all(&(*info)->cpus.fetch);
if ((*info)->nodes.anchor)
free((*info)->nodes.anchor);
if ((*info)->nodes.hist.tics)
free((*info)->nodes.hist.tics);
if ((*info)->nodes.fetch.items)
free((*info)->nodes.fetch.items);
if ((*info)->nodes.fetch.extents)
extents_free_all(&(*info)->nodes.fetch);
if ((*info)->cpu_summary.items)
free((*info)->cpu_summary.items);
if ((*info)->cpu_summary.extents)
extents_free_all(&(*info)->cpu_summary);
if ((*info)->select.items)
free((*info)->select.items);
if ((*info)->select.extents)
extents_free_all(&(*info)->select);
#ifndef NUMA_DISABLE
#ifndef PRETEND_NUMA
if ((*info)->libnuma_handle)
dlclose((*info)->libnuma_handle);
#endif
#endif
free(*info);
*info = NULL;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
return 0;
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
return (*info)->refcount;
} // end: procps_stat_unref
PROCPS_EXPORT signed long long procps_stat_get (
struct procps_statinfo *info,
enum stat_item item)
{
static time_t sav_secs;
time_t cur_secs;
int rc;
/* no sense reading the stat with every call from a program like vmstat
who chooses not to use the much more efficient 'select' function ... */
cur_secs = time(NULL);
library; add more of my gratuitous changes, <STAT> api This commit is just my usual tweaking after an initial submission, once the dust has settled & some more desk checking was performed. Here are the changes included: . get function need not check the 'stat_was_read' flag ( first time in save_sec == 0 so branch always taken ) . some table logic appeared outside the proper section . cleanup_stack's loop made to work like assign_result . eliminated an include of procps.h from stat.h header . removed 'ext_numitems' from the stacks_extent struct . changed the alignment of three prototypes for stat.h . reorganized the pointers for 'stacks_extents' struct . improved types indentation in header for readability . lastly, some really gratuitous changes made to align - comments within that private 'stacks_alloc' function Signed-off-by: Jim Warner <james.warner@comcast.net
2016-05-10 10:30:00 +05:30
if (1 <= cur_secs - sav_secs) {
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if ((rc = read_stat_failed(info)))
return rc;
sav_secs = cur_secs;
}
library: improve internal 'get' processing, <STAT> api With an eye to the future, rather than managing a long switch/case construct in the procps_stat_get function, we'll adopt the approach used in the <meminfo> module. By making 'get' processing table driven too, just like 'select' is already, that may ease future maintenance. Along the way a rather large boo-boo was fixed dealing with that /proc/stat 'procs_running' field which crept in with the commit referenced below. It wasn't spelled correctly and thus was never captured as PROC_RUNNING. Reference(s): commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-01 10:30:00 +05:30
if (item < PROCPS_STAT_logical_end)
return Item_table[item].getsfunc(info);
return -EINVAL;
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
} // end: procps_stat_get
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
/* procps_stat_select():
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* Harvest all the requested TIC and/or SYS information then return
* it in a results stack.
*
* Returns: pointer to a stat_stack struct on success, NULL on error.
*/
PROCPS_EXPORT struct stat_stack *procps_stat_select (
struct procps_statinfo *info,
enum stat_item *items,
int numitems)
{
if (info == NULL || items == NULL)
return NULL;
if (read_stat_failed(info))
return NULL;
return update_single_stack(info, &info->select, items, numitems);
} // end: procps_stat_select
/* procps_stat_reap():
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* Harvest all the requested NUMA NODE and/or CPU information providing the
* result stacks along with totals and the cpu summary.
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
* Returns: pointer to a stat_reaped struct on success, NULL on error.
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
*/
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
PROCPS_EXPORT struct stat_reaped *procps_stat_reap (
struct procps_statinfo *info,
enum stat_reap_type what,
enum stat_item *items,
int numitems)
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
{
library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
int i, rc;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (info == NULL || items == NULL)
return NULL;
info->results.summary = NULL;
info->cpus.result.total = info->nodes.result.total = 0;
info->cpus.result.stacks = info->nodes.result.stacks = NULL;
if (what != STAT_REAP_CPUS_ONLY && what != STAT_REAP_CPUS_AND_NODES)
return NULL;
// those PROCPS_STAT_SYS_type enum's make sense only to 'select' ...
for (i = 0; i < numitems; i++) {
if (items[i] > PROCPS_STAT_TIC_highest)
return NULL;
}
library: readstat redesigned using 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A call to procps_stat_read_jiffs() has been added to those jiffs functions carrying the 'fill' nomenclature to parallel like functions in some of our other files. . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. . Standard copyright boilerplate was added in .c file. . The header file follows the conventions of indenting (by 4 spaces) those parameters too lengthy for 1 line. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 10:30:00 +05:30
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if ((rc = stacks_reconfig_maybe(&info->cpu_summary, items, numitems)) < 0)
return NULL;
if (rc) {
if ((rc = stacks_reconfig_maybe(&info->cpus.fetch, items, numitems)) < 0
|| ((rc = stacks_reconfig_maybe(&info->nodes.fetch, items, numitems)) < 0))
return NULL;
library: extend cpu jiff logic beyond cpu summary info There was not a way I could see to support top's needs for cpu information with the new 'chained' provisions. The sheer quantity of such data plus the unpredictable number of potential processors suggested a totally new approach was warranted while keeping internals opaque. So this patch introduces two new structures solely for use by potential callers (as seen in the API). They're responsible for providing them to the library which is then responsible for filling them with requested data. The top program will continue to provide numa support, without involving the library in any of those details. [ not to mention all the 'dl' and 'stderr' numa crap ] With this transfer of the cpu tics duty to our library the provision associated with the CPU_ZEROTICS #define could not initially be migrated. The commit referenced below suggests it may have lost its importance. In any case such logic may yet be incorporated in the future. But for now, that #define has been completely removed. Reference(s): commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-28 10:30:00 +05:30
}
library: improve/standardize one interface, <STAT> api This commit represents a complete redesign of the stat interface. Gone are the confusing 8 separate accessors along with their 2 additional read functions. In their place we have just 3 accessors, with no read required. That old interface also suffered an inflexibility with respect to structures. Now we deal with an unchanging standard 'result' struct enabling future changes where the binary interface will no longer need to be broken. And gone is that former unnecessary typedef, used when dealing with jiffies. Now the standard C type is used. Our new API also adds some brand new functionality. If a caller plans to employ successive 'select' or 'reap' invocations, then delta values are available (which is actually only what that top program is interested in). At some future point a 'sort' function could be easily introduced to complement the 'reap' function. However, I saw no need for it at present and so it was omitted. There were several design decisions which everyone may not agree with. In support I'll offer these rationals: . The 'get' function returns a signed long long result which means a potential loss of some significance. But I felt the ability to distinguish actual errors (minus values) from true zero results were worth such a risk. . The DELTA item enumerators were also made signed and smaller than their parents. And they are intentionally grouped as last so as to emphasize those distinctions. . The SYS type items were excluded from the new 'reap' function. It would not make sense to duplicate them in each results stack. They're limited to 'get'/'select'. . By the same token, some items (DELTA, etc.) will not be allowed under that 'get' routine. That function was already open to significant internal overhead (through subsequent calls like in vmstat.c). That is why it has been limited via 1 second between reads of /proc/stat. Lastly, when we finally get around to documenting this interface there's a real potential toe stubber when it comes to the numa node portion. The libnuma.so doesn't really provide any means to retrieve the active nodes. Thus, any total reported by <stat> is just the highest node number plus one, as reported by the numa library. Any unused/inactive nodes are identified through these . PROCPS_STAT_TIC_ID shows as PROCPS_STAT_NODE_INVALID By the same token after the STAT_REAP_CPUS_ONLY 'reap' . PROCPS_STAT_TIC_NUMA_NODE = PROCPS_STAT_NODE_INVALID Reference(s): http://www.freelists.org/post/procps/newlib-stat-interface Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-05-06 10:30:00 +05:30
if (read_stat_failed(info))
return NULL;
info->results.summary = update_single_stack(info, &info->cpu_summary, items, numitems);
switch (what) {
case STAT_REAP_CPUS_ONLY:
if (!stacks_fetch_tics(info, &info->cpus))
return NULL;
break;
case STAT_REAP_CPUS_AND_NODES:
if (0 > make_numa_hist(info))
return NULL;
if (!stacks_fetch_tics(info, &info->cpus))
return NULL;
if (!stacks_fetch_tics(info, &info->nodes))
return NULL;
break;
default:
return NULL;
};
return &info->results;
} // end: procps_stat_reap
Reference in New Issue Copy Permalink