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

1208 lines
42 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: 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: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
#include <proc/numa.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
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#include <proc/procps-private.h>
#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
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 <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
#define BUFFER_INCR 4096 // amount i/p buffer allocations grow
library: normalize stack and history allocation naming Recent profiling and timings have resulted in improved newlib performance. This patch completes that process. It just normalizes naming conventions employed for all allocations involving reaped stacks & history support. The modules offering a 'reap' function will also offer the now standardized corresponding STACKS_INCR define. The modules which provide dynamic history support will now have a separate #define called NEWOLD_INCR used in allocations/reallocations. And, while values currently are set equal to that STACKS_INCR value, in the future some reason for divorcing those two may be discovered. ----------------------------- for future reference --- In those modules which contain the STACKS_INCR #define it is tempting to specify a large value so as to avoid repeated calls to malloc/realloc. However, in doing so an extra runtime price will be paid in 'cleanup_stack' calls with any iterative programs like top or slabtop. So, with the current values a balance has been sought. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-09 15:14:44 +05:30
#define STACKS_INCR 32 // amount reap stack allocations grow
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 NEWOLD_INCR 32 // amount jiffs hist allocations grow
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
/* ------------------------------------------------------------------------- +
because 'reap' would be forced to duplicate the global SYS stuff in every |
TIC type results stack, the following #define can be used to enforce that |
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
only STAT_noop and STAT_extra plus all the STAT_TIC items will be allowed | */
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
//#define ENFORCE_LOGICAL // ensure only logical items are accepted by reap |
// ------------------------------------------------------------------------- +
library: add a 'CPU_ZEROTICS' equivalent to <STAT> api This patch just implements an equivalent to the master branch 'CPU_ZEROTICS' provision. However, the original impetus for that earlier implementation was ultimately attributed to a likely kernel anomaly since corrected. As a result, in this newlib implementation we take the opposite approach to the default behavior. There is no adjustment to TIC_SUM_DELTA values if fewer ticks than expected are recorded, unless the define is activated. The commit shown below explains why the 'CPU_ZEROTICS' define was retained in spite of the fix to the kernel. Reference(s): . issue referencing CPU_ZEROTICS https://gitlab.com/procps-ng/procps/issues/132 . master branch CPU_ZEROTICS summary commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 . lengthy thread leading to CPU_ZEROTICS https://www.freelists.org/post/procps/CStates-handling-new-switch Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-06-03 10:30:00 +05:30
/* --------------------------------------------------------------------------+
this next define is equivalent to the master top's CPU_ZEROTICS provision |
except that here in newlib we'll take an opposite approach to our default | */
//#define CPU_IDLE_FORCED // show as 100% idle if fewer ticks than expected |
// --------------------------------------------------------------------------+
#ifdef CPU_IDLE_FORCED
/* this is the % used in establishing a ticks threshold below which some |
cpu will be treated 'idle' rather than reflect misleading tick values | */
#define TICS_THRESHOLD ( 100 / 20 )
#endif
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_jifs {
unsigned long long user, nice, system, idle, iowait, irq, sirq, stolen, guest, gnice;
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
unsigned long long xtot, xbsy, xidl, xusr, xsys;
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
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;
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
int count;
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_jifs new;
struct stat_jifs old;
library: add a 'CPU_ZEROTICS' equivalent to <STAT> api This patch just implements an equivalent to the master branch 'CPU_ZEROTICS' provision. However, the original impetus for that earlier implementation was ultimately attributed to a likely kernel anomaly since corrected. As a result, in this newlib implementation we take the opposite approach to the default behavior. There is no adjustment to TIC_SUM_DELTA values if fewer ticks than expected are recorded, unless the define is activated. The commit shown below explains why the 'CPU_ZEROTICS' define was retained in spite of the fix to the kernel. Reference(s): . issue referencing CPU_ZEROTICS https://gitlab.com/procps-ng/procps/issues/132 . master branch CPU_ZEROTICS summary commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 . lengthy thread leading to CPU_ZEROTICS https://www.freelists.org/post/procps/CStates-handling-new-switch Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-06-03 10:30:00 +05:30
#ifdef CPU_IDLE_FORCED
unsigned long edge; // only valued/valid with cpu summary |
#endif
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: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
struct item_support {
int num; // includes 'logical_end' delimiter
enum stat_item *enums; // includes 'logical_end' delimiter
};
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: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
struct item_support *items; // how these stacks are configured
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 *extents; // anchor for these extents
};
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
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
int n_alloc; // last known anchor pointers allocation
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_stack **anchor; // reapable stacks (consolidated extents)
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
int n_alloc_save; // last known results.stacks allocation
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_reap result; // summary + stacks returned to caller
};
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_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
int refcount;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
FILE *stat_fp;
char *stat_buf; // grows to accommodate all /proc/stat
int stat_buf_size; // current size for the above stat_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
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
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
struct stat_result get_this; // for return to caller after a get
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
struct item_support reap_items; // items used for reap (shared among 3)
struct item_support select_items; // items unique to select
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 ||||||||||||||||||||||||||||||||||||||||||||||||||
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
#define setNAME(e) set_stat_ ## 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
#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: minimize the use of 'cleanup_stacks' routines Some parts of our newlib implementation are the result of functions which have been propagated from module to module. In particular, those 'cleanup_stacks' routines are all similar & likely originated in the <pids> api. In that interface there was a need to free dynamically acquired memory before the result structure was reused to satisfy subsequent 'get', 'select' or 'reap' calls. This, in turn, led to a concept of 'dirty' stacks with the need to call one of two 'cleanup_stack' functions. None of the remaining interfaces deal with such memory yet they each had their own 'cleanup_stack' functions. Those functions were responsible for resetting each of the result unions to zero, excluding any 'noop' items. The bottom line is that for all interfaces, repetitive calls would require iterating through the stack(s) two separate times: once to 'cleanup' another to 'assign'. With this commit we will reduce iterations to just the 'assign' routine. A reset to zero will be accomplished in the 'extra' item set routine (which is the only one actually requiring any reset). All other items will be reinitialized automatically by a new current set value or upon reallocation when an items compliment changes. In the <pids> interface, any freeing of dynamic memory could have been accomplished by adding that 'freefunc' check to the 'assign' function. However, that requires an Item_table test with every item. Instead, we'll now satisfy such needs as the very first step in those set functions responsible for dynamically acquired memory. [ the <pids> api retains 2 'cleanup_stack' functions ] [ to accommodate stack(s) 'reset' & to serve 'unref' ] Lastly, all the 'itemize_stack' functions were tweaked by eliminating an unnecessary initialization of result unions. That objective was already accomplished by the calloc() in a 'stacks_alloc' function or the remaining 'cleanup_stack' routine found in the <pids> interface. Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-05-22 10:30:00 +05:30
setDECL(noop) { (void)R; (void)S; (void)T; }
setDECL(extra) { (void)S; (void)T; R->result.ull_int = 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(TIC_ID) { (void)S; R->result.s_int = T->id; }
setDECL(TIC_NUMA_NODE) { (void)S; R->result.s_int = T->numa_node; }
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
setDECL(TIC_NUM_CONTRIBUTORS) { (void)S; R->result.s_int = T->count; }
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
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)
library: improve header file item comments, <STAT> api This patch just polishes the 'origin' comments for the <STAT> header file. In particular those derived/unique items (the 'SUM' guys) will now be properly explained. [ in order to employ the 'derived from above' phrase ] [ with their DELTA versions, all SUM items had to be ] [ relocated (and some renamed). in turn, that had an ] [ impact on many portions of the .c source file too. ] Reference(s): . summary calculations introduced commit 2c86c4984a15c9ab912402838c6651f466a3d2ed . origins added to header files commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-13 11:30:00 +05:30
TIC_set(TIC_SUM_TOTAL, ull_int, xtot)
TIC_set(TIC_SUM_IDLE, ull_int, xidl)
TIC_set(TIC_SUM_USER, ull_int, xusr)
TIC_set(TIC_SUM_BUSY, ull_int, xbsy)
TIC_set(TIC_SUM_SYSTEM, ull_int, xsys)
TICsetH(TIC_SUM_DELTA_TOTAL, sl_int, xtot)
TICsetH(TIC_SUM_DELTA_IDLE, sl_int, xidl)
TICsetH(TIC_SUM_DELTA_USER, sl_int, xusr)
TICsetH(TIC_SUM_DELTA_BUSY, sl_int, xbsy)
TICsetH(TIC_SUM_DELTA_SYSTEM, sl_int, xsys)
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +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
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; }
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
#undef setDECL
#undef TIC_set
#undef SYS_set
#undef TICsetH
#undef SYSsetH
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
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
// ___ Sorting Support ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
struct sort_parms {
int offset;
enum stat_sort_order order;
};
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
#define srtNAME(t) sort_stat_ ## t
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
#define srtDECL(t) static int srtNAME(t) \
(const struct stat_stack **A, const struct stat_stack **B, struct sort_parms *P)
srtDECL(s_int) {
const struct stat_result *a = (*A)->head + P->offset; \
const struct stat_result *b = (*B)->head + P->offset; \
return P->order * (a->result.s_int - b->result.s_int);
}
srtDECL(sl_int) {
const struct stat_result *a = (*A)->head + P->offset; \
const struct stat_result *b = (*B)->head + P->offset; \
return P->order * (a->result.sl_int - b->result.sl_int);
}
srtDECL(ul_int) {
const struct stat_result *a = (*A)->head + P->offset; \
const struct stat_result *b = (*B)->head + P->offset; \
if ( a->result.ul_int > b->result.ul_int ) return P->order > 0 ? 1 : -1; \
if ( a->result.ul_int < b->result.ul_int ) return P->order > 0 ? -1 : 1; \
return 0;
}
srtDECL(ull_int) {
const struct stat_result *a = (*A)->head + P->offset; \
const struct stat_result *b = (*B)->head + P->offset; \
if ( a->result.ull_int > b->result.ull_int ) return P->order > 0 ? 1 : -1; \
if ( a->result.ull_int < b->result.ull_int ) return P->order > 0 ? -1 : 1; \
return 0;
}
srtDECL(noop) { \
(void)A; (void)B; (void)P; \
return 0;
}
#undef srtDECL
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: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
typedef int (*QSR_t)(const void *, const void *, void *);
#define QS(t) (QSR_t)srtNAME(t)
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
#define TS(t) STRINGIFY(t)
#define TS_noop ""
library: improve/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: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
QSR_t sortfunc; // sort cmp func for a specific type
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
char *type2str; // the result type as a string value
library: improve/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: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
/* setsfunc sortfunc type2str
--------------------------- ------------ ----------- */
{ RS(noop), QS(noop), TS_noop },
{ RS(extra), QS(ull_int), TS_noop },
{ RS(TIC_ID), QS(s_int), TS(s_int) },
{ RS(TIC_NUMA_NODE), QS(s_int), TS(s_int) },
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
{ RS(TIC_NUM_CONTRIBUTORS), QS(s_int), TS(s_int) },
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ RS(TIC_USER), QS(ull_int), TS(ull_int) },
{ RS(TIC_NICE), QS(ull_int), TS(ull_int) },
{ RS(TIC_SYSTEM), QS(ull_int), TS(ull_int) },
{ RS(TIC_IDLE), QS(ull_int), TS(ull_int) },
{ RS(TIC_IOWAIT), QS(ull_int), TS(ull_int) },
{ RS(TIC_IRQ), QS(ull_int), TS(ull_int) },
{ RS(TIC_SOFTIRQ), QS(ull_int), TS(ull_int) },
{ RS(TIC_STOLEN), QS(ull_int), TS(ull_int) },
{ RS(TIC_GUEST), QS(ull_int), TS(ull_int) },
{ RS(TIC_GUEST_NICE), QS(ull_int), TS(ull_int) },
{ RS(TIC_DELTA_USER), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_NICE), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_SYSTEM), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_IDLE), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_IOWAIT), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_IRQ), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_SOFTIRQ), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_STOLEN), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_GUEST), QS(sl_int), TS(sl_int) },
{ RS(TIC_DELTA_GUEST_NICE), QS(sl_int), TS(sl_int) },
library: improve header file item comments, <STAT> api This patch just polishes the 'origin' comments for the <STAT> header file. In particular those derived/unique items (the 'SUM' guys) will now be properly explained. [ in order to employ the 'derived from above' phrase ] [ with their DELTA versions, all SUM items had to be ] [ relocated (and some renamed). in turn, that had an ] [ impact on many portions of the .c source file too. ] Reference(s): . summary calculations introduced commit 2c86c4984a15c9ab912402838c6651f466a3d2ed . origins added to header files commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-13 11:30:00 +05:30
{ RS(TIC_SUM_TOTAL), QS(ull_int), TS(ull_int) },
{ RS(TIC_SUM_IDLE), QS(ull_int), TS(ull_int) },
{ RS(TIC_SUM_USER), QS(ull_int), TS(ull_int) },
{ RS(TIC_SUM_BUSY), QS(ull_int), TS(ull_int) },
{ RS(TIC_SUM_SYSTEM), QS(ull_int), TS(ull_int) },
{ RS(TIC_SUM_DELTA_TOTAL), QS(sl_int), TS(sl_int) },
{ RS(TIC_SUM_DELTA_IDLE), QS(sl_int), TS(sl_int) },
{ RS(TIC_SUM_DELTA_USER), QS(sl_int), TS(sl_int) },
{ RS(TIC_SUM_DELTA_BUSY), QS(sl_int), TS(sl_int) },
{ RS(TIC_SUM_DELTA_SYSTEM), QS(sl_int), TS(sl_int) },
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ RS(SYS_CTX_SWITCHES), QS(ul_int), TS(ul_int) },
{ RS(SYS_INTERRUPTS), QS(ul_int), TS(ul_int) },
{ RS(SYS_PROC_BLOCKED), QS(ul_int), TS(ul_int) },
{ RS(SYS_PROC_CREATED), QS(ul_int), TS(ul_int) },
{ RS(SYS_PROC_RUNNING), QS(ul_int), TS(ul_int) },
{ RS(SYS_TIME_OF_BOOT), QS(ul_int), TS(ul_int) },
{ RS(SYS_DELTA_CTX_SWITCHES), QS(s_int), TS(s_int) },
{ RS(SYS_DELTA_INTERRUPTS), QS(s_int), TS(s_int) },
{ RS(SYS_DELTA_PROC_BLOCKED), QS(s_int), TS(s_int) },
{ RS(SYS_DELTA_PROC_CREATED), QS(s_int), TS(s_int) },
{ RS(SYS_DELTA_PROC_RUNNING), QS(s_int), TS(s_int) },
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
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// dummy entry corresponding to STAT_logical_end ...
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
{ NULL, NULL, 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 */
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#ifdef ENFORCE_LOGICAL
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
enum stat_item STAT_TIC_highest = STAT_TIC_DELTA_GUEST_NICE;
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#endif
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
enum stat_item STAT_logical_end = 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
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
#undef srtNAME
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 RS
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
#undef QS
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline void stat_assign_results (
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_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;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (item >= STAT_logical_end)
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
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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_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
misc: eliminate all those remaining gcc -Wall warnings Reference(s): proc/readproc.c: In function 'statm2proc' proc/readproc.c:600:9: warning: variable 'num' set but not used [-Wunused-but-set-variable] proc/stat.c: In function 'stat_derive_unique': proc/stat.c:429:1: warning: no return statement in function returning non-void [-Wreturn-type] ps/parser.c: In function 'arg_type': ps/parser.c:1098:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation] ps/parser.c:1099:34: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' lib/signals.c: In function 'strtosig': lib/signals.c:243:9: warning: this 'if' clause does not guard... [-Wmisleading-indentation] lib/signals.c:245:13: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' slabtop.c: In function 'print_summary': slabtop.c:223:29: warning: unused variable 'stats' [-Wunused-variable] watch.c: In function 'process_ansi': watch.c:232:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation] watch.c:235:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:32:00 +05:30
static inline void stat_derive_unique (
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
struct hist_tic *this)
{
/* note: we exclude guest tics from xtot since ...
'user' already includes 'guest'
'nice' already includes 'gnice'
( see: ./kernel/sched/cputime.c, account_guest_time ) */
this->new.xtot
= this->new.user
+ this->new.nice
+ this->new.system
+ this->new.idle
+ this->new.iowait
+ this->new.irq
+ this->new.sirq
+ this->new.stolen;
this->new.xusr = this->new.user + this->new.nice;
/* this stolen guy is one i'm not sure of yet, but it's documented as:
"the time spent in other operating systems
when running in a virtualized environment"
so it would seem to apply to an 'involuntary wait' for a guest OS */
this->new.xidl = this->new.idle + this->new.iowait + this->new.stolen;
this->new.xbsy = this->new.xtot - this->new.xidl;
this->new.xsys = this->new.xbsy - this->new.xusr;
library: improve <STAT> cpus offline/online management When those standardized 'derived' TIC enumerators were introduced, a problem with potential DELTA distortions was also introduced when toggling cpus offline/online. It has always been true that the 1st (summary) line in /proc/stat will experience a decrease in total tics if a new cpu is brought online. Such decreases are mostly due to reductions in 'idle' and 'iowait' tics. Exactly why such a counterintuitive phenomenon should occur is a mystery, but this has been acknowledged in proc.txt. A separate potential distortion arises with individual cpus. And, here it extends to both bringing processors online plus taking them offline too. When that happens the order of the cpus array tracking is upset, placing the 'new' values in some other processor's array slot. But even if we were to occupy the same slot, the issue regarding reductions in 'idle' & 'iowait' still apply. In all cases, when a DELTA field was found to be minus it was forced to zero via the 'TICsetH' macro. However the 'derived' calculations are subject to new forms of distortion with their own DELTA values. For example we could find DELTA_SUM_USER + DELTA_SUM_SYSTEM exceeding DELTA_SUM_TOTAL, an illogical/inappropriate condition. So this commit moves former protections for individual cpus to the stat_derive_unique() function and modifies it to also extend protections to the 'derived' values. In the process we now protect the cpu 'summary' counts which were unfortunately previously overlooked (oops). Reference(s): . 'derived' types introduced commit 2c86c4984a15c9ab912402838c6651f466a3d2ed
2017-03-22 10:30:00 +05:30
// don't distort deltas when cpus are taken offline or brought online
if (this->new.xtot < this->old.xtot
|| (this->new.xusr < this->old.xusr)
|| (this->new.xidl < this->old.xidl)
|| (this->new.xbsy < this->old.xbsy)
|| (this->new.xsys < this->old.xsys))
memcpy(&this->old, &this->new, sizeof(struct stat_jifs));
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
} // end: stat_derive_unique
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static void stat_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: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
while (this->extents) {
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 *p = this->extents;
this->extents = this->extents->next;
free(p);
library: standardize extents_free_all() logic, 3rd gen As those 3rd generation newlib APIs evolved so too did the extents_free_all() function. Most versions of this function required the callers to first verify that the extents anchor wasn't empty, which was poor etiquette. This simple function should have been much more robust and forgiving. With this commit, it fnally becomes so. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
};
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline struct stat_result *stat_itemize_stack (
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,
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;
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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_itemize_stack
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static inline int stat_items_check_failed (
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,
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 *'
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
* my_stack = procps_stat_select(info, STAT_noop, num);
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 (numitems < 1
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
|| (void *)items < (void *)(unsigned long)(2 * STAT_logical_end))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 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
for (i = 0; i < numitems; i++) {
// a stat_item is currently unsigned, but we'll protect our future
if (items[i] < 0)
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (items[i] >= STAT_logical_end) {
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int stat_make_numa_hist (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *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
struct hist_tic *cpu_ptr, *nod_ptr;
int i, node;
/* 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 ) */
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
if (!(info->nodes.total = numa_max_node() + 1))
return 0;
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
library: improve support of dynamic numa nodes, <stat> If, in fact, numa nodes are dynamic (like that current total of on-line cpus) the existing logic was lacking. It included an early return before checking the total. So, this commit ensures that the nodes total is always set or updated consistently in only a single function. There's no need to set it at the time 'new' is called. [ and since under our existing code this nodes total ] [ could never possibly have been zero, the erroneous ] [ test (with the early return) has now been whacked! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 12:52:22 +05:30
if (info->nodes.hist.n_alloc == 0
|| (info->nodes.total >= info->nodes.hist.n_alloc)) {
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_alloc = info->nodes.total + NEWOLD_INCR;
info->nodes.hist.tics = realloc(info->nodes.hist.tics, info->nodes.hist.n_alloc * sizeof(struct hist_tic));
library: improve support of dynamic numa nodes, <stat> If, in fact, numa nodes are dynamic (like that current total of on-line cpus) the existing logic was lacking. It included an early return before checking the total. So, this commit ensures that the nodes total is always set or updated consistently in only a single function. There's no need to set it at the time 'new' is called. [ and since under our existing code this nodes total ] [ could never possibly have been zero, the erroneous ] [ test (with the early return) has now been whacked! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 12:52:22 +05:30
if (info->nodes.hist.tics == 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
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;
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
for (i = 0; i < info->nodes.total; i++) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
nod_ptr->id = nod_ptr->numa_node = STAT_NODE_INVALID;
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
++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;
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
if (-1 < (node = numa_node_of_cpu(cpu_ptr->id))) {
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
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;
library <stat>: added overlooked numa guest tic counts When this module was upgraded to 3rd generation in the patch referenced below, numa node support was migrated from the top program into newlib. The 'guest_nice' and 'guest' tics were overlooked as top did not need them. So, this commit corrects that oversight and achieves a proper symmetry between the cpu & numa jiffies counts. Reference(s): . 3rd gen redesign, numa support imported commit abc71a46ada71b790eb526d6cddb91e0d0aed4cb Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-21 18:38:08 +05:30
nod_ptr->new.guest += cpu_ptr->new.guest; nod_ptr->old.guest += cpu_ptr->old.guest;
nod_ptr->new.gnice += cpu_ptr->new.gnice; nod_ptr->old.gnice += cpu_ptr->old.gnice;
library: finally circumvent libnuma memory leak <stat> Still unhappy with a minor memory leak associated with libnuma, I experimented with omitting the dlclose that was issued at module's end. For some reason which will remain a mystery, the valgrind leak then went bye-bye. So this patch just omits one use of dlclose and relies on whatever kernel magic is at work to free the memory when each process ends. We kept, however, the original code (now commented-out) to serve as a future caution. There remains one potential (but unlikely) dlclose use near the original dlopen. But there will be no leak as that 'numa_node_of_cpu' will not yet have been called. This seems to be the culprit that triggers such leaks. None of this libnuma shit would likely have come close to hitting our fan had the numa developers provided us with 'new' and 'unref' functions like our newlib does. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-13 01:45:15 +05:30
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
nod_ptr->new.xtot += cpu_ptr->new.xtot; nod_ptr->old.xtot += cpu_ptr->old.xtot;
nod_ptr->new.xbsy += cpu_ptr->new.xbsy; nod_ptr->old.xbsy += cpu_ptr->old.xbsy;
nod_ptr->new.xidl += cpu_ptr->new.xidl; nod_ptr->old.xidl += cpu_ptr->old.xidl;
nod_ptr->new.xusr += cpu_ptr->new.xusr; nod_ptr->old.xusr += cpu_ptr->old.xusr;
nod_ptr->new.xsys += cpu_ptr->new.xsys; nod_ptr->old.xsys += cpu_ptr->old.xsys;
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->numa_node = node;
nod_ptr->id = node;
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
nod_ptr->count++; ;
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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int stat_read_failed (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *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;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
char *bp, *b;
int i, rc, num, tot_read;
unsigned long long llnum;
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->cpus.hist.n_alloc) {
info->cpus.hist.tics = calloc(NEWOLD_INCR, sizeof(struct hist_tic));
if (!(info->cpus.hist.tics))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 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
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
}
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
if (!info->stat_fp
&& (!(info->stat_fp = fopen(STAT_FILE, "r"))))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
fflush(info->stat_fp);
rewind(info->stat_fp);
#define maxSIZ info->stat_buf_size
#define curSIZ ( maxSIZ - tot_read )
#define curPOS ( info->stat_buf + tot_read )
/* we slurp in the entire directory thus avoiding repeated calls to fread, |
especially in a massively parallel environment. additionally, each cpu |
line is then frozen in time rather than changing until we get around to |
accessing it. this helps to minimize (not eliminate) some distortions. | */
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
tot_read = 0;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
while ((0 < (num = fread(curPOS, 1, curSIZ, info->stat_fp)))) {
tot_read += num;
if (tot_read < maxSIZ)
break;
maxSIZ += BUFFER_INCR;
if (!(info->stat_buf = realloc(info->stat_buf, maxSIZ)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
};
#undef maxSIZ
#undef curSIZ
#undef curPOS
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: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (!feof(info->stat_fp)) {
errno = EIO;
return 1;
}
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
info->stat_buf[tot_read] = '\0';
bp = info->stat_buf;
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
sum_ptr = &info->cpu_hist;
// remember summary from last time around
memcpy(&sum_ptr->old, &sum_ptr->new, sizeof(struct stat_jifs));
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
sum_ptr->id = STAT_SUMMARY_ID; // mark as summary
sum_ptr->numa_node = STAT_NODE_INVALID; // mark as invalid
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
// 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
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
, &sum_ptr->new.guest, &sum_ptr->new.gnice)) {
errno = ERANGE;
return 1;
}
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
stat_derive_unique(sum_ptr);
library: add a 'CPU_ZEROTICS' equivalent to <STAT> api This patch just implements an equivalent to the master branch 'CPU_ZEROTICS' provision. However, the original impetus for that earlier implementation was ultimately attributed to a likely kernel anomaly since corrected. As a result, in this newlib implementation we take the opposite approach to the default behavior. There is no adjustment to TIC_SUM_DELTA values if fewer ticks than expected are recorded, unless the define is activated. The commit shown below explains why the 'CPU_ZEROTICS' define was retained in spite of the fix to the kernel. Reference(s): . issue referencing CPU_ZEROTICS https://gitlab.com/procps-ng/procps/issues/132 . master branch CPU_ZEROTICS summary commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 . lengthy thread leading to CPU_ZEROTICS https://www.freelists.org/post/procps/CStates-handling-new-switch Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-06-03 10:30:00 +05:30
#ifdef CPU_IDLE_FORCED
/* if any cpu accumulated substantially fewer tics than what is expected |
we'll force it to be treated as 'idle' so as not to return misleading |
statistics (and that sum_ptr->count also serves as first time switch) | */
if (sum_ptr->count) sum_ptr->edge =
((sum_ptr->new.xtot - sum_ptr->old.xtot) / sum_ptr->count) / TICS_THRESHOLD;
#endif
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));
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
// next can be overridden under 'stat_make_numa_hist'
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
cpu_ptr->numa_node = STAT_NODE_INVALID;
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
cpu_ptr->count = 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
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))) {
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 <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
stat_derive_unique(cpu_ptr);
library: add a 'CPU_ZEROTICS' equivalent to <STAT> api This patch just implements an equivalent to the master branch 'CPU_ZEROTICS' provision. However, the original impetus for that earlier implementation was ultimately attributed to a likely kernel anomaly since corrected. As a result, in this newlib implementation we take the opposite approach to the default behavior. There is no adjustment to TIC_SUM_DELTA values if fewer ticks than expected are recorded, unless the define is activated. The commit shown below explains why the 'CPU_ZEROTICS' define was retained in spite of the fix to the kernel. Reference(s): . issue referencing CPU_ZEROTICS https://gitlab.com/procps-ng/procps/issues/132 . master branch CPU_ZEROTICS summary commit ee3ed4b45edd66c6e0455d3fab08a48e7ea83030 . lengthy thread leading to CPU_ZEROTICS https://www.freelists.org/post/procps/CStates-handling-new-switch Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-06-03 10:30:00 +05:30
#ifdef CPU_IDLE_FORCED
// first time through (that priming read) sum_ptr->edge will be zero |
if (cpu_ptr->new.xtot < sum_ptr->edge) {
cpu_ptr->old.xtot = cpu_ptr->old.xbsy = cpu_ptr->old.xidl = cpu_ptr->old.xusr = cpu_ptr->old.xsys
= cpu_ptr->new.xbsy = cpu_ptr->new.xusr = cpu_ptr->new.xsys = 0;
cpu_ptr->new.xtot = cpu_ptr->new.xidl = 1;
}
#endif
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
++cpu_ptr;
library <stat>: improve response to cpu offline/online With the addition of those new derived SUM values, any CPUs taken offline or brought online would distort the historical (delta) results. So this patch just forces a history reset when such transitions are encountered. Reference(s): . derived SUM provisions introduced commit 2c86c4984a15c9ab912402838c6651f466a3d2ed Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
++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
} 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: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return 1;
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
goto reap_em_again;
}
library <stat>: standardized new category calculations This commit arose out of the discussion (and research) surrounding the issue cited below. It is an attempt to consolidate and standardize the calculation of jiffies categories (e.g. 'idle', 'busy', etc.) once & for all. Also included is the enum STAT_TIC_NUM_CONTRIBUTORS in case anyone, in the future, decides to calculate usage based upon elapsed time * Hz (like top does in process level %CPU stats). In such an event, a total number of CPUs or NUMA Nodes would be needed for proper scaling. Reference(s): https://gitlab.com/procps-ng/procps/issues/48 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-27 19:38:08 +05:30
info->cpus.total = info->cpus.hist.n_inuse = sum_ptr->count = 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
// remember sys_hist stuff from last time around
memcpy(&info->sys_hist.old, &info->sys_hist.new, sizeof(struct stat_data));
llnum = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if ((b = strstr(bp, "intr ")))
sscanf(b, "intr %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.intr = llnum;
llnum = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if ((b = strstr(bp, "ctxt ")))
sscanf(b, "ctxt %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.ctxt = llnum;
llnum = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if ((b = strstr(bp, "btime ")))
sscanf(b, "btime %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.btime = llnum;
llnum = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if ((b = strstr(bp, "processes ")))
sscanf(b, "processes %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_created = llnum;
llnum = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if ((b = strstr(bp, "procs_blocked ")))
sscanf(b, "procs_blocked %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_blocked = llnum;
llnum = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if ((b = strstr(bp, "procs_running ")))
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;
return 0;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_read_failed
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
/*
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* stat_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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
* associated context structure.
library: 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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static struct stacks_extent *stat_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;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 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->items->num; // 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 one single blob, facilitating a later free(). |
as a minimum, it is important that those result structures themselves always be |
contiguous within each 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 final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
p_head->head = stat_itemize_stack((struct stat_result *)v_list, this->items->num, this->items->enums);
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_blob->stacks[i] = p_head;
v_list += list_size;
v_head += head_size;
}
p_blob->ext_numstacks = maxstacks;
return p_blob;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_stacks_alloc
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int stat_stacks_fetch (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *info,
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 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: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
#define n_alloc this->n_alloc
#define n_inuse this->hist.n_inuse
#define n_saved this->n_alloc_save
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
// initialize stuff -----------------------------------
if (!this->anchor) {
if (!(this->anchor = calloc(sizeof(void *), STACKS_INCR)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1;
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
n_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) {
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (!(ext = stat_stacks_alloc(&this->fetch, n_alloc)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1; // here, errno was set to ENOMEM
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
memcpy(this->anchor, ext->stacks, sizeof(void *) * n_alloc);
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
}
// iterate stuff --------------------------------------
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
for (i = 0; i < n_inuse; i++) {
if (!(i < n_alloc)) {
n_alloc += STACKS_INCR;
if ((!(this->anchor = realloc(this->anchor, sizeof(void *) * n_alloc)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
|| (!(ext = stat_stacks_alloc(&this->fetch, STACKS_INCR))))
return -1; // here, errno was set to 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
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_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 -------------------------------------
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
/* note: we go to this trouble of maintaining a duplicate of the consolidated |
extent stacks addresses represented as our 'anchor' since these ptrs |
are exposed to a user (um, not that we don't trust 'em or anything). |
plus, we can NULL delimit these ptrs which we couldn't do otherwise. | */
if (n_saved < i + 1) {
n_saved = i + 1;
if (!(this->result.stacks = realloc(this->result.stacks, sizeof(void *) * n_saved)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1;
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
}
memcpy(this->result.stacks, this->anchor, sizeof(void *) * i);
this->result.stacks[i] = 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
this->result.total = i;
library: bug fix if libnuma.so unavailable, <STAT> api All our numa logic was well encapsulated under #ifndef NUMA_DISABLE (as ./configure --disable-numa), with the exception of 1 case label. The reason it didn't create any problems is because the sole consumer (top) itself responded to the presence of #define NUMA_DISABLE too. But if that option wasn't used, an oops still awaited. When experimenting with a 32-bit library plus a 64-bit kernel, a bug was revealed should the numa library not have been found. Our 'reap' function must tolerate the potential of a 0 return from that stacks_fetch_tics(). Now, if numa is desired but not possible, we'll be ok. [ and, we'll build numa history from fresher sources ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-17 10:30:00 +05:30
// callers beware, this might be zero (maybe no libnuma.so) ...
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 this->result.total;
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
#undef n_alloc
#undef n_inuse
#undef n_saved
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_stacks_fetch
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static int stat_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)
{
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (stat_items_check_failed(numitems, items))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 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
/* is this the first time or have things changed since we were last called?
if so, gotta' redo all of our stacks stuff ... */
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if (this->items->num != numitems + 1
|| memcmp(this->items->enums, items, sizeof(enum stat_item) * numitems)) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// allow for our STAT_logical_end
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if (!(this->items->enums = realloc(this->items->enums, sizeof(enum stat_item) * (numitems + 1))))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -1;
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
memcpy(this->items->enums, items, sizeof(enum stat_item) * numitems);
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
this->items->enums[numitems] = STAT_logical_end;
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
this->items->num = numitems + 1;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_extents_free_all(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
return 1;
}
return 0;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_stacks_reconfig_maybe
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
static struct stat_stack *stat_update_single_stack (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *info,
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 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
{
if (!this->extents
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
&& !(stat_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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_assign_results(this->extents->stacks[0], &info->sys_hist, &info->cpu_hist);
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 this->extents->stacks[0];
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
} // end: stat_update_single_stack
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
// ___ 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: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
// --- standard required functions --------------------------------------------
library: 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: some minor miscellaeous improvements, 3rd gen A collection of miscellaneous code and comment tweaks. [ such changes will stop when desk checking ends too ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-13 10:30:00 +05:30
* Returns: < 0 on failure, 0 on success along with
* a pointer to a new context struct
library: 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 (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info **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: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *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: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (!(p = calloc(1, sizeof(struct stat_info))))
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 -ENOMEM;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
if (!(p->stat_buf = calloc(1, BUFFER_INCR))) {
free(p);
return -ENOMEM;
}
p->stat_buf_size = BUFFER_INCR;
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;
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 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->results.cpus = &p->cpus.result;
p->results.nodes = &p->nodes.result;
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
// these 3 are for reap, sharing a single set of items
p->cpu_summary.items = p->cpus.fetch.items = p->nodes.fetch.items = &p->reap_items;
// the select guy has its own set of items
p->select.items = &p->select_items;
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
numa_init();
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 priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 15:14:44 +05:30
/* do a priming read here for the following potential benefits: |
1) ensure there will be no problems with subsequent access |
library: eliminate distorted history 1st time switches Upon reflection, at the point where the 'priming read' was introduced, any possibility of history distortions was also eliminated. This was true because all of the 'old' (zeroed) data will have been replaced with 'new' data whenever a user finally calls get, select & reap. Thus, any DELTA values will automatically reflect that interval between 'new' and subsequent retrieval calls. [ diskstats didn't actually employ a 1st time switch ] [ like the others so we have changed a comment only. ] [ but that module will retain something similar used ] [ inside node_update whenever a new node is created. ] Reference(s): . priming read added to slabinfo commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 . priming read added to diskstats commit ecd64f444593a0badf6db6a27fcbc46a3888551d . priming read added to meminfo, stat, vmstat commit 1a2b62c7793f5f6865eec56a6f996e55495725bf Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
2) make delta results potentially useful, even if 1st time |
3) elimnate need for history distortions 1st time 'switch' | */
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (stat_read_failed(p)) {
library: add priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 15:14:44 +05:30
procps_stat_unref(&p);
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return -errno;
library: add priming read at 'new' time <most modules> A priming read at 'new' time in that <slabinfo> module was important so that permission problems are detected early. Plus, it also had the potential of making delta values valid when 'get' or 'select' were first called. It is for that latter reason that such a read was also incorporated in the <diskstats> module 'new' function. No other module, however, employed such priming reads. This patch just brings those potential benefits to all of our other newlib modules with the exception of that <pids> guy. That module is, of necessity, sufficiently different from those others to justify such exclusion. Not only are there precious few DELTA enums in <pids>, but the costs of a priming read would be much greater. [ otherwise, these newly added priming reads have no ] [ measurable negative impact on performance/timings. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-17 15:14:44 +05:30
}
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 = 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 (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *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 (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info **info)
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: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
library: 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--;
library: protect against possible 'refcount' underflow In each module employing a priming read at 'new' time, should that read fail, a call to 'unref' will be made. However, there is a hidden dependency that these calls must never occur before the context 'refcount' was set due to the way an 'unref' conditional was constructed. So this commit just ensures that 'unref' will function as expected, even if called with a 'refcount' of zero. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-11-22 20:40:10 +05:30
if ((*info)->refcount < 1) {
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
int errno_sav = errno;
library <stat>: input file buffer size must be dynamic Since its introduction, our evolved /proc/stat API has relied on a static buffer of 8192 bytes. This approach is probably Ok for other /proc files but it would only accommodate around 100 processors. If such a threshold were exceeded then this interface could never succeed. Now days 100 processors doesn't seem at all excessive. So this commit trades that static buffer for a dynamic self-tuning one. And since so much former top CPU code was already rolled into this module, we just stole the already proven top dynamic buffer management code too. [ this also meant switching low level unbuffered I/O ] [ calls to standard library buffered I/O calls. that ] [ is exactly what <slabinfo> and <diskstats> employ. ] Reference(s): . 1st gen readstat introduction commit a410e236abb47c7c43194e61d0566686f81513af Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-12-31 11:30:00 +05:30
if ((*info)->stat_fp)
fclose((*info)->stat_fp);
if ((*info)->stat_buf)
free((*info)->stat_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
if ((*info)->cpus.anchor)
free((*info)->cpus.anchor);
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if ((*info)->cpus.result.stacks)
free((*info)->cpus.result.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
if ((*info)->cpus.hist.tics)
free((*info)->cpus.hist.tics);
if ((*info)->cpus.fetch.extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_extents_free_all(&(*info)->cpus.fetch);
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)->nodes.anchor)
free((*info)->nodes.anchor);
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if ((*info)->nodes.result.stacks)
free((*info)->nodes.result.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
if ((*info)->nodes.hist.tics)
free((*info)->nodes.hist.tics);
if ((*info)->nodes.fetch.extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_extents_free_all(&(*info)->nodes.fetch);
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)->cpu_summary.extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_extents_free_all(&(*info)->cpu_summary);
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)->select.extents)
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_extents_free_all(&(*info)->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
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if ((*info)->reap_items.enums)
free((*info)->reap_items.enums);
if ((*info)->select_items.enums)
free((*info)->select_items.enums);
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 10:33:00 +05:30
numa_uninit();
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
free(*info);
*info = NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = errno_sav;
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
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
// --- variable interface functions -------------------------------------------
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
PROCPS_EXPORT struct stat_result *procps_stat_get (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *info,
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)
{
static time_t sav_secs;
time_t cur_secs;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
if (info == NULL)
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (item < 0 || item >= STAT_logical_end)
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
library: more tweaks for code and/or comments, 3rd gen Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . eliminated duplicate decl of 'struct procps_meminfo' . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . how did i miss relocating all these friggin' #undefs . cleanup 'get' return logic (remove a redundant 'if') <pids> ............................................... . repositioned the procps_pidsinfo structure in header . removed the extra trailing comma from enum pids_item . standardized/normalized results struct union members <slabinfo> ........................................... . corrected comment typo (jeeze, in an 'aligned' para) . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . removed an obsolete #undef from procps_slabinfo_sort . cleanup 'get' return logic (remove a redundant 'if') <stat> ............................................... . how did i miss relocating all these friggin' #undefs . corrected an initialization fencepost used with numa <=== see Craig, here's a bug fix . removed the extra trailing comma from enum stat_item . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . strengthen those parm checks in procps_stat_get func . cleanup 'get' return logic (remove a redundant 'if') <vmstat> ............................................. . standardized/normalized results struct union members . added 'std' & 'var' dividers in .c file, like <pids> . cleanup 'get' return logic (remove a redundant 'if') [ virtually all of these tweaks reflect the author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-14 10:30:00 +05:30
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
/* we will NOT read the source file with every call - rather, we'll offer
a granularity of 1 second between reads ... */
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
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: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (stat_read_failed(info))
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
return NULL;
library: improve/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
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
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
info->get_this.item = item;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
// with 'get', we must NOT honor the usual 'noop' guarantee
info->get_this.result.ull_int = 0;
library: <STAT> api, change for that 'get' return type The following commit message is shared with 4 patches. ------------------------------------------------------ Under the newlib interface most of our 'get' functions represent a bit of a compromise in that the actual raw values are coerced into one (probably ok) return type. That approach creates the possibility of truncation at best, and wouldn't serve future needs should something other than numeric data be added to the 'get' results. This commit trades the current compromise for a return value guaranteed to satisfy all future needs, namely a pointer to a particular api's specific results struct. The impact on existing programs is minimal, especially when using a new supplied macro. Otherwise, native 'C' syntax could be used, but may feel somewhat unnatural. [ as an aside, this new approach allows us to delete ] [ all 'getsfunc' table entries & the supporting code ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-18 10:30:00 +05:30
Item_table[item].setsfunc(&info->get_this, &info->sys_hist, &info->cpu_hist);
return &info->get_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: 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_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 (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *info,
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_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: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
int 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 and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 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 == NULL || items == NULL)
return NULL;
if (what != STAT_REAP_CPUS_ONLY && what != STAT_REAP_CPUS_AND_NODES)
return NULL;
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
#ifdef ENFORCE_LOGICAL
{ int i;
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
// those STAT_SYS_type enum's make sense only to '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
for (i = 0; i < numitems; i++) {
library: removed all the 'PROCPS_' enumerator prefixes Many of our item enumerator identifiers are very long, especially in that <VMSTAT> module. Additionally, they all contain the exact same universal 'PROCPS_' prefix. The origins for this are likely found in the desire to avoid name clashes with other potential include files. But with procps-ng newlib, we've probably gone way too far. Did 'PROCPS_PIDS_TICS_SYSTEM' actually offer more protection against clash than 'PIDS_TICS_SYSTEM' does? I don't think so. Besides, no matter how big that name becomes, one can never guarantee they'll never be some clash. And, conversely, extremely short names will not always create conflict. Of course, in either case when some clash occurs, one can always #undef that problem. Thus, this commit will eliminate that 'PROCPS_' prefix making all of those enum identifiers a little shorter. And, we'll still be well above some ridiculously short (criminally short) names found in some common headers: - - - - - - - - - - <term.h> - 'tab', 'TTY', etc - - - - - - - - - - - - - - - - <search.h> - 'ENTER', ENTRY', 'FIND', etc ------------------------------------------------------ Finally, with this as a last of the wholesale changes, we will have established the naming conventions below: . only functions will begin with that 'procps_' prefix . exposed structures begin with the module/header name . item enumerators begin like structs, but capitalized . other enumerators work exactly like item enumerators . macros and constants begin just like the enumerators ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
if (items[i] > STAT_TIC_highest)
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;
}
library: final tweaks to code and/or comments, 3rd gen With the dust now settling on all those 3rd generation upgrades, this patch tries to provide some consistency among the separate modules involved. Someday we should consider a 4th generation where all redundant code has been removed and isolated in a new shared source file. Following is a summary of significant changes (if any) to each of these now upgraded 3rd gen library modules. <meminfo> ............................................ . strictly formatting/comment changes, code unaffected <pids> ............................................... . replaced a local mkSTR macro with existing STRINGIFY . added fetch narrative explaining duplicate addresses <slabinfo> ........................................... . rearranged some free logic for procps_slabinfo_unref . added fetch narrative explaining duplicate addresses <stat> ............................................... . added #define ENFORCE_LOGICAL, just as in <slabinfo> . replaced a local mkSTR macro with existing STRINGIFY . alphabetized the function declarations in the header <vmstat> ............................................. . made one coverity concession with read_vmstat_failed [ several of these changes may reflect this author's ] [ continuing pursuit of an unreasonable goal -- that ] [ of a 'perfect' (plus 'pretty') C language program! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 10:30:00 +05:30
}
#endif
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (0 > (rc = stat_stacks_reconfig_maybe(&info->cpu_summary, items, numitems)))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return NULL; // here, errno may be overridden with 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
if (rc) {
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
stat_extents_free_all(&info->cpus.fetch);
stat_extents_free_all(&info->nodes.fetch);
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 and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 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
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (stat_read_failed(info))
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;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
info->results.summary = stat_update_single_stack(info, &info->cpu_summary);
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 final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
/* unlike the other 'reap' functions, <stat> provides for two separate |
stacks pointer arrays exposed to callers. Thus, to keep our promise |
of NULL delimit we must ensure a minimal array for the optional one | */
library: refactor exposed pointers management, 3rd gen This commit brings all of those 'fetch' type functions (supporting some form of 'reap') into closer alignment with one another. The biggest impact is to be found in the <stat> module, which now provides for the separate copy of stack pointers which will be exposed to users. The reason such a copy was not employed initially with <stat>, unlike those for <pids> and <slabinfo>, is due to the fact that such stacks were never sortable. Thus the original raw consolidated extent pointers wouldn't have been disturbed. But that meant no NULL delimiter. So with this commit, all reap/fetch operations now use pointer copies when returning results to callers. And, all such arrays are now NULL delimited meaning callers can choose their own access fencepost: totals or NULL. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if (!info->nodes.result.stacks
&& (!(info->nodes.result.stacks = malloc(sizeof(void *)))))
return NULL;
info->nodes.result.total = 0;
info->nodes.result.stacks[0] = 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
switch (what) {
case STAT_REAP_CPUS_ONLY:
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (0 > stat_stacks_fetch(info, &info->cpus))
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;
break;
case STAT_REAP_CPUS_AND_NODES:
library: strictly cosmetic, absolutely no code changes This commit just contains some tweaks to comments plus a few adjustments to whitespace for alignment purposes and a normalization of the header inclusion #define's. [ plus a spelling error in one header file was fixed ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-09-28 20:40:10 +05:30
/* note: if we're doing numa at all, we must do this numa history |
library: improve header file item comments, <STAT> api This patch just polishes the 'origin' comments for the <STAT> header file. In particular those derived/unique items (the 'SUM' guys) will now be properly explained. [ in order to employ the 'derived from above' phrase ] [ with their DELTA versions, all SUM items had to be ] [ relocated (and some renamed). in turn, that had an ] [ impact on many portions of the .c source file too. ] Reference(s): . summary calculations introduced commit 2c86c4984a15c9ab912402838c6651f466a3d2ed . origins added to header files commit 96d59cbf46b3ff687bd29fad4708074a0e1cea14 Signed-off-by: Jim Warner <james.warner@comcast.net>
2019-01-13 11:30:00 +05:30
before we build (fetch) cpu stacks since that stat_read_failed |
guy always marks (temporarily) all the cpu node ids as invalid | */
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (0 > stat_make_numa_hist(info))
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;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
if (0 > stat_stacks_fetch(info, &info->nodes))
return NULL;
if (0 > stat_stacks_fetch(info, &info->cpus))
library: partial revert of that numa 'fix', <STAT> api This patch represents the partial revert of the commit referenced below. And, so that yours truly (the author for goodness sake) doesn't shoot his tootsies again in the future, a cautionary programmer comment was added. Reference(s): commit dea403341886d7cc8338fd14461835794625b6a1 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-22 10:30:00 +05:30
return 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
break;
default:
return NULL;
};
return &info->results;
} // end: procps_stat_reap
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
/* procps_stat_select():
*
* 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 (
library: standardize all the 'context' structure names This patch attempts to standardize the naming of those most important (declared not defined) context structs. The present practice represents a hodge podge of names only some of which reflect the source /proc file name. And 2 of those file names embed a literal 'info' which is likely the origin of that required parm identifier. Now we'll append a universal '_info' to such structure names, while including the names of those /proc pseudo files where possible. In any case, that context struct will *always* begin with the actual module/header file name. And only the following two sound a little weird! ---------> 'meminfo_info' + 'slabinfo_info' <--------- Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 10:30:00 +05:30
struct stat_info *info,
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
enum stat_item *items,
int numitems)
{
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
if (info == NULL || items == NULL)
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (0 > stat_stacks_reconfig_maybe(&info->select, items, numitems))
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
return NULL; // here, errno may be overridden with ENOMEM
errno = 0;
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
if (stat_read_failed(info))
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
return NULL;
library: most function names now more profile friendly This patch will begin some refinements associated with gprof. Initially, functions names have been changed to help in identifying potential bottlenecks. This effort also included the obscure set, free and sort routines. Plus the following additional modifications were made: . the stacks_alloc prologue was generalized plus added to a couple of modules where it had not yet propagated . a couple of the '// end ...' comments were corrected . some functions have been formally tagged as 'inline' Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-21 10:30:00 +05:30
return stat_update_single_stack(info, &info->select);
library: reduce copies of items to minimum, <STAT> api This commit will consolidate the three separate copies of the item enumerators currently supporting that reap function (summary, cpus & nodes) into one shared copy. That select function will continue to maintain its own dedicated items copy, albeit via a new item structure. [ and while we're at it, we'll move the 'select' guy ] [ to its proper alphabetical place, after our 'reap' ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-01 10:30:00 +05:30
} // end: procps_stat_select
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
/*
* procps_stat_sort():
*
* Sort stacks anchored in the passed stack pointers array
* based on the designated sort enumerator and specified order.
*
* Returns those same addresses sorted.
*
* Note: all of the stacks must be homogeneous (of equal length and content).
*/
PROCPS_EXPORT struct stat_stack **procps_stat_sort (
struct stat_info *info,
struct stat_stack *stacks[],
int numstacked,
enum stat_item sortitem,
enum stat_sort_order order)
{
struct stat_result *p;
struct sort_parms parms;
int offset;
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = EINVAL;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
if (info == NULL || stacks == NULL)
return NULL;
// a stat_item is currently unsigned, but we'll protect our future
if (sortitem < 0 || sortitem >= STAT_logical_end)
return NULL;
if (order != STAT_SORT_ASCEND && order != STAT_SORT_DESCEND)
return NULL;
if (numstacked < 2)
return stacks;
offset = 0;
p = stacks[0]->head;
for (;;) {
if (p->item == sortitem)
break;
++offset;
if (p->item >= STAT_logical_end)
return NULL;
++p;
}
library: improve and/or standardize 'errno' management With older library logic having been modified to avoid using those potentially deadly alloc.h routines, while improving 'errno' handling, we're ready to standardize and enhance newlib's approach to any potential errors. In so doing, we'll establish the following objectives: . . . . . . . . . . . . . functions returning an 'int' . an error will be indicated by a negative number that is always the inverse of some well known errno.h value . . . . . . . . . . . functions returning an 'address' . any error will be indicated by a NULL return pointer with the actual reason found in the formal errno value And, when errno is manipulated directly we will strive to do so whenever possible within those routines which have been declared with PROCPS_EXPORT. In other words, in the user callable functions defined in source last. [ But, that won't always be possible. In particular, ] [ all the 'read_failed' functions will sometimes set ] [ 'errno' so that they can serve callers returning a ] [ NULL or an int without duplicating a lot of logic. ] [ Also, that includes one subordinate function which ] [ was called by 'read_failed' in the <slabinfo> API. ] ------------------------------------------------------ Along the way, several additional miscellaneous issues were addressed. They're listed here now for posterity. . the '-1' return value passed outside the library was eliminated since it would erroneously equate to -EPERM . the stacks_fetch functions in <diskstats> and <stat> weren't checked for their possible minus return values . hash create was not checked in <meminfo> or <vmstat> . fixed 'new' function faulty parm check in <slabinfo> Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-11-18 10:30:00 +05:30
errno = 0;
library: add final remaining sort function, <STAT> api With this patch, all of the modules which offer a reap function (pids, diskstats, slabinfo and stat too) will now also provide for sorting whatever had been reaped. It was easy to overlook a sort function for our <STAT> guy given the paucity of CPUs on your typical personal desktop or laptop. However, out in the world one might find boxes with hundreds of CPUs plus many NUMA nodes. Hey, who are we to disallow sorts on something another person might see as useful under the above conditions? And, there's always something to be said for symmetry. [ of course, several minor tweaks were also included ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-24 10:30:00 +05:30
parms.offset = offset;
parms.order = order;
qsort_r(stacks, numstacked, sizeof(void *), (QSR_t)Item_table[p->item].sortfunc, &parms);
return stacks;
} // end: procps_stat_sort
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
// --- special debugging function(s) ------------------------------------------
/*
* The following isn't part of the normal programming interface. Rather,
* it exists to validate result types referenced in application programs.
*
* It's used only when:
* 1) the 'XTRA_PROCPS_DEBUG' has been defined, or
* 2) the '#include <proc/xtra-procps-debug.h>' used
*/
PROCPS_EXPORT struct stat_result *xtra_stat_get (
struct stat_info *info,
enum stat_item actual_enum,
const char *typestr,
const char *file,
int lineno)
{
struct stat_result *r = procps_stat_get(info, actual_enum);
library: ensure that all those 'GET' macros are robust When users call the native 'get' functions they have a responsibility to check that the result struct address was indeed returned. But when using those 'GET' macros there was no protection for possible NULL dereference. So this patch will add some protection for a potential failure of an underlying 'get' function. And should it occur then those 'GET' macros will just return a zero. Plus, we'll also mirror that behavior in the debugging header should the XTRA_PROCPS_DEBUG #define be active. And, we might as well add a warning when invalid items are passed to 'GET' macros, just like we do for 'VAL'. [ lastly, we added the missing opening parens/braces ] [ to 2 'GET' macros in that xtra-procps-debug.h file ] [ which went unnoticed until the qa folks caught up. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-06 21:41:11 +05:30
if (actual_enum < 0 || actual_enum >= STAT_logical_end) {
fprintf(stderr, "%s line %d: invalid item = %d, type = %s\n"
, file, lineno, actual_enum, typestr);
}
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (r) {
char *str = Item_table[r->item].type2str;
if (str[0]
&& (strcmp(typestr, str)))
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
}
return r;
} // end: xtra_stat_get_
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
PROCPS_EXPORT struct stat_result *xtra_stat_val (
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
int relative_enum,
const char *typestr,
const struct stat_stack *stack,
struct stat_info *info,
const char *file,
int lineno)
{
char *str;
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
int i;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
for (i = 0; stack->head[i].item < STAT_logical_end; i++)
;
if (relative_enum < 0 || relative_enum >= i) {
fprintf(stderr, "%s line %d: invalid relative_enum = %d, type = %s\n"
, file, lineno, relative_enum, typestr);
return NULL;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
}
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
str = Item_table[stack->head[relative_enum].item].type2str;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
if (str[0]
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
&& (strcmp(typestr, str))) {
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
fprintf(stderr, "%s line %d: was %s, expected %s\n", file, lineno, typestr, str);
library: strengthen the VAL macro validation functions One ought not to assume that random memory access will always succeed or, when it does, that an obviously bad item enumerator will always be found at that location. Thus, this patch corrects some really poor assumptions associated with the 'xtra_procps_debug.h' header file. [ and it does so in somewhat contorted ways so as to ] [ avoid several darn gcc -Wnonnull warning messages! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-08 11:53:45 +05:30
}
return &stack->head[relative_enum];
library: clean up some miscellaneous compiler warnings Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-06-03 10:30:00 +05:30
(void)info;
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 10:30:00 +05:30
} // end: xtra_stat_val
Reference in New Issue Copy Permalink