mirrors/procps
0
0
Fork 0
mirror of https://gitlab.com/procps-ng/procps.git synced 2024-11-24 10:35:17 +08:00
Code Issues Packages Projects Releases Wiki Activity
c4d097c709
procps/slabtop.c

378 lines
12 KiB
C
Raw Normal View History

slabtop: new usage & fix coding style Coding style fixed and more readable help output. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-05 00:58:25 +08:00
/*
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
* slabtop.c - utility to display kernel slab information.
*
* Chris Rivera <cmrivera@ufl.edu>
* Robert Love <rml@tech9.net>
*
* Copyright (C) 2003 Chris Rivera
docs: clarification to license headers in files Add license header to all files. The summary of licensing is below, taken from Craig Small's email which is referred in commit message tail. sysctl and pgrep are GPL 2+ The rest is LGPL 2.1+ Reference: http://www.freelists.org/post/procps/Incorrect-FSF-address-in-the-license-files,8 Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=797962 CC: Craig Small <csmall@enc.com.au> CC: Jaromir Capik <jcapik@redhat.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-02 20:29:36 +08:00
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
*/
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
#include <ctype.h>
#include <errno.h>
#include <getopt.h>
slabtop: added remaining missing nls support
2011-11-04 00:07:47 +08:00
#include <locale.h>
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
#include <ncurses.h>
#include <signal.h>
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
#include <stdio.h>
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
#include <stdlib.h>
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
#include <string.h>
#include <termios.h>
compile with glibc 2.2.17 and older
2005-01-06 04:50:54 +08:00
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
#include <sys/ioctl.h>
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
#include <sys/select.h>
compile with glibc 2.2.17 and older
2005-01-06 04:50:54 +08:00
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
slabtop: add gettext support Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-09 08:49:51 +08:00
#include "c.h"
all: check stdout and stderr status at exit If stream status is not checked at the end of execution below problem would not report error, or non-zero exit code. The uptime is just an example same was true with all commands of the project. $ uptime >&- ; echo $? uptime: write error: Bad file descriptor 1 $ uptime >/dev/full ; echo $? uptime: write error: No space left on device 1 Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-23 20:32:24 +08:00
#include "fileutils.h"
slabtop: add gettext support Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-09 08:49:51 +08:00
#include "nls.h"
slabtop: use strutils.c to validate user input This commit fixes also peculiar behavior of $ slabtop -d 0 which did not make sense. The fix is to disallow anything else but positive integers, which includes zero as is is not positive (or negative) number. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-12-18 22:12:06 +08:00
#include "strutils.h"
library: cleanup of library includes The includes used to define a lot of things a library include should not. It was also a bit messy what was exposed in the library and what was not. get_pid_digits -> procps_pid_length and exported correctly MALLOC attribute move into relevant .c files NORETURN attribute moved to relevant .c, not used in library PURE attribute removed, it wasn't used KLONG/KLF/STRTOUKL were fixed for long, so now just use long HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT seems to do the same (opposite) thing. likely/unlikely removed from most places, its highly debateable this does anything useful as CPUs have gotten smarter about branches. Re-arranged the includes, ALL external programs should just #include <proc/procps.h> then proc/procps.h includes headers for files that have exported functions. procps.h and the headers it includes should not use items that are not exportable (e.g. hidden functions or macros) they go in procps-private.h
2016-04-16 15:03:57 +08:00
#include <proc/procps.h>
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
#define DEFAULT_SORT PROCPS_SLABNODE_OBJS
#define CHAINS_ALLOC 150
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
#define MAXTBL(t) (int)( sizeof(t) / sizeof(t[0]) )
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static unsigned short Cols, Rows;
static struct termios Saved_tty;
static long Delay = 3;
static int Run_once = 0;
related: adapt to changes in 'context' structure names Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-21 13:00:00 +08:00
static struct slabinfo_info *Slab_info;
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
enum slabinfo_item Sort_item = DEFAULT_SORT;
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
enum slabinfo_sort_order Sort_Order = PROCPS_SLABINFO_DESCEND;
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
enum slabinfo_item Node_items[] = {
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
PROCPS_SLABNODE_OBJS, PROCPS_SLABNODE_AOBJS, PROCPS_SLABNODE_USE,
PROCPS_SLABNODE_OBJ_SIZE, PROCPS_SLABNODE_SLABS, PROCPS_SLABNODE_OBJS_PER_SLAB,
PROCPS_SLABNODE_SIZE, PROCPS_SLABNODE_NAME,
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
/* next 2 are sortable but are not displayable,
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
thus they need not be represented in the Relative_enums */
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
PROCPS_SLABNODE_PAGES_PER_SLAB, PROCPS_SLABNODE_ASLABS };
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
enum Relative_enums {
my_OBJS, my_AOBJS, my_USE, my_OSIZE,
my_SLABS, my_OPS, my_SIZE, my_NAME };
#define MAX_ITEMS (int)(sizeof(Node_items) / sizeof(Node_items[0]))
#define PRINT_line(fmt, ...) if (Run_once) printf(fmt, __VA_ARGS__); else printw(fmt, __VA_ARGS__)
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
/*
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
* term_resize - set the globals 'Cols' and 'Rows' to the current terminal size
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
*/
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static void term_resize (int unusused __attribute__ ((__unused__)))
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
{
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
struct winsize ws;
if ((ioctl(STDOUT_FILENO, TIOCGWINSZ, &ws) != -1) && ws.ws_row > 10) {
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
Cols = ws.ws_col;
Rows = ws.ws_row;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
} else {
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
Cols = 80;
Rows = 24;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
}
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static void sigint_handler (int unused __attribute__ ((__unused__)))
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
{
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
Delay = 0;
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static void __attribute__((__noreturn__)) usage (FILE *out)
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
{
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
fputs(USAGE_HEADER, out);
fprintf(out, _(" %s [options]\n"), program_invocation_short_name);
fputs(USAGE_OPTIONS, out);
fputs(_(" -d, --delay <secs> delay updates\n"), out);
fputs(_(" -o, --once only display once, then exit\n"), out);
fputs(_(" -s, --sort <char> specify sort criteria by character (see below)\n"), out);
fputs(USAGE_SEPARATOR, out);
fputs(USAGE_HELP, out);
fputs(USAGE_VERSION, out);
fputs(_("\nThe following are valid sort criteria:\n"), out);
fputs(_(" a: sort by number of active objects\n"), out);
fputs(_(" b: sort by objects per slab\n"), out);
fputs(_(" c: sort by cache size\n"), out);
fputs(_(" l: sort by number of slabs\n"), out);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
fputs(_(" v: sort by (non display) number of active slabs\n"), out);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
fputs(_(" n: sort by name\n"), out);
fputs(_(" o: sort by number of objects (the default)\n"), out);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
fputs(_(" p: sort by (non display) pages per slab\n"), out);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
fputs(_(" s: sort by object size\n"), out);
fputs(_(" u: sort by cache utilization\n"), out);
fprintf(out, USAGE_MAN_TAIL("slabtop(1)"));
exit(out == stderr ? EXIT_FAILURE : EXIT_SUCCESS);
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
}
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
static void set_sort_stuff (const char key)
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
{
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = DEFAULT_SORT;
Sort_Order = PROCPS_SLABINFO_DESCEND;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
switch (tolower(key)) {
case 'n':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_NAME;
Sort_Order = PROCPS_SLABINFO_ASCEND;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'o':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_OBJS;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'a':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_AOBJS;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 's':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_OBJ_SIZE;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'b':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_OBJS_PER_SLAB;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'p':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_PAGES_PER_SLAB;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'l':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_SLABS;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'v':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_ASLABS;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'c':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_SIZE;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
case 'u':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
Sort_item = PROCPS_SLABNODE_USE;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
default:
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
}
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static void parse_opts (int argc, char **argv)
{
static const struct option longopts[] = {
{ "delay", required_argument, NULL, 'd' },
{ "sort", required_argument, NULL, 's' },
{ "once", no_argument, NULL, 'o' },
{ "help", no_argument, NULL, 'h' },
{ "version", no_argument, NULL, 'V' },
{ NULL, 0, NULL, 0 }};
int o;
while ((o = getopt_long(argc, argv, "d:s:ohV", longopts, NULL)) != -1) {
switch (o) {
case 'd':
errno = 0;
Delay = strtol_or_err(optarg, _("illegal delay"));
if (Delay < 1)
xerrx(EXIT_FAILURE, _("delay must be positive integer"));
break;
case 's':
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
set_sort_stuff(optarg[0]);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
break;
case 'o':
Run_once=1;
Delay = 0;
break;
case 'V':
printf(PROCPS_NG_VERSION);
exit(EXIT_SUCCESS);
case 'h':
usage(stdout);
default:
usage(stderr);
}
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
}
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static void print_summary (void)
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
{
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
enum slabinfo_item items[] = {
PROCPS_SLABS_AOBJS, PROCPS_SLABS_OBJS,
PROCPS_SLABS_ASLABS, PROCPS_SLABS_SLABS,
PROCPS_SLABS_ACACHES, PROCPS_SLABS_CACHES,
PROCPS_SLABS_SIZE_ACTIVE, PROCPS_SLABS_SIZE_TOTAL,
PROCPS_SLABS_SIZE_MIN, PROCPS_SLABS_SIZE_AVG,
PROCPS_SLABS_SIZE_MAX
};
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
enum slabs_enums {
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
stat_AOBJS, stat_OBJS, stat_ASLABS, stat_SLABS,
stat_ACACHES, stat_CACHES, stat_ACTIVE, stat_TOTAL,
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
stat_MIN, stat_AVG, stat_MAX
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
};
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
struct slabinfo_stack *p;
struct slabinfo_result *stats;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
if (!(p = procps_slabinfo_select(Slab_info, items, MAXTBL(items))))
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
xerrx(EXIT_FAILURE, _("Error getting slab summary results"));
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
/* we really should use the provided PROCPS_SLABINFO_VAL macro but,
let's do this instead to salvage as much original code as possible ... */
stats = p->head;
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
PRINT_line(" %-35s: %u / %u (%.1f%%)\n"
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
, /* Translation Hint: Next five strings must not
* exceed a length of 35 characters. */
/* xgettext:no-c-format */
_("Active / Total Objects (% used)")
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
, stats[stat_AOBJS].result.u_int
, stats[stat_OBJS ].result.u_int
, 100.0 * stats[stat_AOBJS].result.u_int / stats[stat_OBJS].result.u_int);
PRINT_line(" %-35s: %u / %u (%.1f%%)\n"
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
, /* xgettext:no-c-format */
_("Active / Total Slabs (% used)")
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
, stats[stat_ASLABS].result.u_int
, stats[stat_SLABS ].result.u_int
, 100.0 * stats[stat_ASLABS].result.u_int / stats[stat_SLABS].result.u_int);
PRINT_line(" %-35s: %u / %u (%.1f%%)\n"
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
, /* xgettext:no-c-format */
_("Active / Total Caches (% used)")
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
, stats[stat_ACACHES].result.u_int
, stats[stat_CACHES ].result.u_int
, 100.0 * stats[stat_ACACHES].result.u_int / stats[stat_CACHES].result.u_int);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
PRINT_line(" %-35s: %.2fK / %.2fK (%.1f%%)\n"
, /* xgettext:no-c-format */
_("Active / Total Size (% used)")
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
, stats[stat_ACTIVE].result.ul_int / 1024.0
, stats[stat_TOTAL ].result.ul_int / 1024.0
, 100.0 * stats[stat_ACTIVE].result.ul_int / stats[stat_TOTAL].result.ul_int);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
PRINT_line(" %-35s: %.2fK / %.2fK / %.2fK\n\n"
, _("Minimum / Average / Maximum Object")
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
, stats[stat_MIN].result.u_int / 1024.0
, stats[stat_AVG].result.u_int / 1024.0
, stats[stat_MAX].result.u_int / 1024.0);
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
static void print_headings (void)
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
{
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
/* Translation Hint: Please keep alignment of the
* following intact. */
PRINT_line("%-78s\n", _(" OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME"));
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
}
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
static void print_details (struct slabinfo_stack *stack)
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
{
library: slab is redesigned to use 'stack' vs. 'chain' In addition to that text shown below the line which is common to several commit messages, this patch contains several minor changes with lessor impact upon the API: . A 'read' was added to function procps_slabnode_count (but only when necessary, i.e. info->nodes_used == 0). . The #include header files are ordered alphabetically now, with all those <sys/??> types separately grouped. ------------------------------------------------------ . The former 'chains' have now become 'stacks' without the 'next' pointer in each result struct. The pointers initially seemed to offer some flexibility with memory allocations and benefits for the library access logic. However, user access was always via displacement and a a statically allocated chain was cumbersome to define. . An enumerator ending in '_noop' will no longer serve as a fencepost delimiter. Rather, it has become a much more important and flexible user oriented tool. Adding one or more such 'items' in any items list passed into the library becomes the means of extending the 'stack' to also include user (not just library) data. Any such data is guaranteed to never be altered by the library. . Anticipating PID support, where many different types must be represented in a result structure, we'll adopt a common naming standard. And, while not every results structure currently needs to reflect disparate types a union will be employed so the same dot qualifier ('.') can be used consistently when accessing all such data. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-21 13:00:00 +08:00
PRINT_line("%6u %6u %3u%% %7.2fK %6u %8u %9luK %-23s\n"
, stack->head[my_OBJS ].result.u_int
, stack->head[my_AOBJS].result.u_int
, stack->head[my_USE ].result.u_int
, stack->head[my_OSIZE].result.u_int / 1024.0
, stack->head[my_SLABS].result.u_int
, stack->head[my_OPS ].result.u_int
, stack->head[my_SIZE ].result.ul_int / 1024
, stack->head[my_NAME ].result.str);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
return;
}
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
int main(int argc, char *argv[])
{
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
int is_tty, rc = EXIT_SUCCESS;
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
unsigned short old_rows;
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
configure: check for program_invocation_name For portabiliy, check for program_invocation_name during configure and define HAVE_PROGRAM_INVOCATION_NAME accordingly. Use of this symbol is now enclosed with the appropriate #ifdef block. The symbol program_invocation_name is only used for error message handling using error(), so it's safe to omit this if it is not available.
2013-02-21 01:31:48 +08:00
#ifdef HAVE_PROGRAM_INVOCATION_NAME
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
program_invocation_name = program_invocation_short_name;
configure: check for program_invocation_name For portabiliy, check for program_invocation_name during configure and define HAVE_PROGRAM_INVOCATION_NAME accordingly. Use of this symbol is now enclosed with the appropriate #ifdef block. The symbol program_invocation_name is only used for error message handling using error(), so it's safe to omit this if it is not available.
2013-02-21 01:31:48 +08:00
#endif
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
setlocale (LC_ALL, "");
bindtextdomain(PACKAGE, LOCALEDIR);
textdomain(PACKAGE);
atexit(close_stdout);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
parse_opts(argc, argv);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
if (procps_slabinfo_new(&Slab_info) < 0)
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
xerr(EXIT_FAILURE, _("Unable to create slabinfo structure"));
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
if (!Run_once) {
is_tty = isatty(STDIN_FILENO);
if (is_tty && tcgetattr(STDIN_FILENO, &Saved_tty) == -1)
xwarn(_("terminal setting retrieval"));
old_rows = Rows;
term_resize(0);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
initscr();
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
resizeterm(Rows, Cols);
signal(SIGWINCH, term_resize);
signal(SIGINT, sigint_handler);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
}
do {
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
struct slabinfo_reap *reaped;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
struct timeval tv;
fd_set readfds;
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
int i;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
if (!(reaped = procps_slabinfo_reap(Slab_info, Node_items, MAXTBL(Node_items)))) {
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
xwarn(_("Unable to get slabinfo node data"));
rc = EXIT_FAILURE;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
break;
}
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
if (!(procps_slabinfo_sort(Slab_info, reaped->stacks, reaped->total, Sort_item, Sort_Order))) {
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
xwarn(_("Unable to sort slab nodes"));
rc = EXIT_FAILURE;
break;
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
if (Run_once) {
print_summary();
print_headings();
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
for (i = 0; i < reaped->total; i++)
print_details(reaped->stacks[i]);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
break;
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
if (old_rows != Rows) {
resizeterm(Rows, Cols);
old_rows = Rows;
}
move(0, 0);
print_summary();
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
attron(A_REVERSE);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
print_headings();
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
attroff(A_REVERSE);
misc: adapted other pgms to changes in, <SLABINFO> api Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
for (i = 0; i < Rows - 8 && i < reaped->total; i++)
print_details(reaped->stacks[i]);
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
refresh();
FD_ZERO(&readfds);
FD_SET(STDIN_FILENO, &readfds);
tv.tv_sec = Delay;
tv.tv_usec = 0;
if (select(STDOUT_FILENO, &readfds, NULL, NULL, &tv) > 0) {
char c;
if (read(STDIN_FILENO, &c, 1) != 1
|| (c == 'Q' || c == 'q'))
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
break;
slabtop: correct the sort behavior for that NAME field When our <SLABINFO> was recently re-designed, the sort callback functions became table driven, whereas before a single callback used switch/case constructs based on an 'item'. Thus, sorting was made a tad more efficient but, it introduced a buglet into that slabtop program. The root cause of this bug was the fact that the field NAME required a low-to-high sort and all other slabtop fields used high-to-low. Fortunately, along with those <SLABINFO> table driven sort changes, that i/f offered users the option of either low-to-high or high-to-low. So this patch just exploits that choice. And, it means that such responsibilities are now properly located in calling code, not in what's a general purpose library. Reference(s): . most recent lib sort enhancement & breakage commit 5d5a52a3804f912f7be8c15f18bf87fe45bbcd99 Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-09 13:00:00 +08:00
set_sort_stuff(c);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
}
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
// made zero by sigint_handler()
} while (Delay);
library: rebase & make current initial slabinfo effort This was Craig's original patch, referenced below, but it was never pushed to newlib. It has now been rebased on top of some diskstat stuff to serve as a beginning. The original effort was perfectly serviceable (after a memory leak was fixed) but the approach would not have served future PID needs when that proc_t went bye bye. The slabtop requirements are similar to those of PIDs. One must accommodate the variable number of slab nodes (PIDs) while also accepting different data (char * and unsigned long). Furthermore, some generalized means to sort all that acquired stuff must somehow be provided. So I wanted to try a different approach that seemed to hold potential for satisfying future top and ps needs. Subsequent commits will make that attempt, building on Craig's original patch whose commit msg appears below. ------------------------------------------------------ All of the /proc/slabinfo related calls have been changed here. They follow the same procps_slabinfo_* format. Made both the slabtop and vmstat programs use the new API as one was using the old one and one was just sort of trying to do its own thing. Sorting of slabnodes is also possible via the library. Reference(s): http://www.freelists.org/post/procps/Sorting-slabsprocesses,3 http://www.freelists.org/post/procps/library-rework-slabinfo-calls Signed-off-by: Craig Small <csmall@enc.com.au> Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-04 12:59:59 +08:00
slabtop: adapted to exploit new alloc & sort interface In addition to the new interface several other changes were made. In fact, there are so many I must apologize in advance to Craig, et al. for the hatchet I wielded. Among the changes was my attempt to shrink the body of that main() function. It's amazing how some folks must always cram as code much as possible into ol' main(). Personally, unless it's a throwaway quick & dirty pgm, all main function bodies should not exceed one screen. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-07-11 13:00:00 +08:00
if (!Run_once) {
if (is_tty)
tcsetattr(STDIN_FILENO, TCSAFLUSH, &Saved_tty);
endwin();
}
procps_slabinfo_unref(&Slab_info);
return rc;
add slabtop, fix top ^Z terminal handling
2004-01-25 06:33:56 +08:00
}
Reference in New Issue Copy Permalink