Command line and full screen utilities for browsing procfs, a "pseudo" file system dynamically generated by Linux to provide information about the status of entries in its process table.
acda6f40d1
This patch contains the following miscellaneous stuff: . The pids_stacks_fetch() routine might call for newly allocated stacks to be itemized. However, that job was already tended to by the pids_stacks_alloc() function. So, this patch just eliminates a redundant invocation. ------------------------------------------------------ . The concept of 'dirty_stacks' has not kept pace with the evolving stacks implementation. Originally, stacks were considered dirty only if free() of dynamic memory was needed before refreshing any single result struct. Later, with the introduction of the 'extra' item and a promise to reset it to zero, 'dirty' was much broader. So, this patch just treats the dirty flg as others do. ------------------------------------------------------ . Lastly, a word or three about performance & timings. Tuning efforts concentrated on the <pids> API and top. And unless an oldlib equivalent to the preceding patch is applied (favoring stat vs. status), newlib top will often outperform the oldlib version (obviously wrong). So assuming /proc/stat is preferred in both libraries, generally speaking, a cpu and elapsed time increase of 1-5% was found for this new stacks oriented interface. Of course, there's also an increased memory footprint. There are some occasions, however, when the newlib top is at a substantial disadvantage. For example if WCHAN or TTY is displayed, such items will be present in all newlib reaped stacks (i.e. every process). But old top would only incur such overhead with displayable tasks. Thus, oldlib top could outperform newlib by up to 25%, for example, if only fields requiring NO library flags were displayed. However, such a scenario is not likely since only GID, UID, PID, TGID & WCHAN would be shown. In the usual case, that overhead associated with WCHAN and/or TTY is overshadowed by other top runtime costs. All in all a pleasing outcome I deem quite acceptable. ------------------------------------------------------ Signed-off-by: Jim Warner <james.warner@comcast.net> |
||
|---|---|---|
| contrib | ||
| doc | ||
| Documentation | ||
| include | ||
| lib | ||
| man-po | ||
| misc | ||
| po | ||
| proc | ||
| ps | ||
| testsuite | ||
| top | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| AUTHORS | ||
| autogen.sh | ||
| ChangeLog | ||
| configure.ac | ||
| COPYING | ||
| COPYING.LIB | ||
| create-man-pot.sh | ||
| free.1 | ||
| free.c | ||
| INSTALL.md | ||
| kill.1 | ||
| kill.c | ||
| Makefile.am | ||
| NEWS | ||
| pgrep.1 | ||
| pgrep.c | ||
| pidof.1 | ||
| pidof.c | ||
| pkill.1 | ||
| pmap.1 | ||
| pmap.c | ||
| pwdx.1 | ||
| pwdx.c | ||
| README.md | ||
| skill.1 | ||
| skill.c | ||
| slabtop.1 | ||
| slabtop.c | ||
| snice.1 | ||
| sysctl.8 | ||
| sysctl.c | ||
| sysctl.conf | ||
| sysctl.conf.5 | ||
| tload.1 | ||
| tload.c | ||
| translate-man.sh | ||
| uptime.1 | ||
| uptime.c | ||
| vmstat.8 | ||
| vmstat.c | ||
| w.1 | ||
| w.c | ||
| watch.1 | ||
| watch.c | ||
procps
procps is a set of command line and full-screen utilities that provide information out of the pseudo-filesystem most commonly located at /proc. This filesystem provides a simple interface to the kernel data structures. The programs of procps generally concentrate on the structures that describe the processess running on the system.
The following programs are found in procps:
- free - Report the amount of free and used memory in the system
- kill - Send a signal to a process based on PID
- pgrep - List processes based on name or other attributes
- pkill - Send a signal to a process based on name or other attributes
- pmap - Report memory map of a process
- ps - Report information of processes
- pwdx - Report current directory of a process
- skill - Obsolete version of pgrep/pkill
- slabtop - Display kernel slab cache information in real time
- snice - Renice a process
- sysctl - Read or Write kernel parameters at run-time
- tload - Graphical representation of system load average
- top - Dynamic real-time view of running processes
- uptime - Display how long the system has been running
- vmstat - Report virtual memory statistics
- w - Report logged in users and what they are doing
- watch - Execute a program periodically, showing output fullscreen
Reporting Bugs
There are a few ways of reporting bugs or feature requests:
- Your distributions bug reporter. If you are using a distribution your first port of call is their bug tracker. This is because each distribution has their own patches and way of dealing with bugs. Also bug reporting often does not need any subscription to websites.
- GitLab Issues - To the left of this page is the issue tracker. You can report bugs here.
- Email list - We have an email list (see below) where you can report bugs. The problem with this method is bug reports often get lost and cannot be tracked. This is especially a big problem when its something that will take time to resolve.
If you need to report bugs, there is more details on the Bug Reporting page.
Email List
The email list for the developers and users of procps is found at http://www.freelists.org/archive/procps/ This email list discusses the development of procps and is used by distributions to also forward or discuss bugs.