This commit adds a new switch -a/--available that
appends a new column called 'available' to the
output. The column displays an estimation
of how much memory is available for starting
new applications, without swapping. Unlike the data
provided by the 'cached' or 'free' fields, this
field takes into account page cache and also that
not all reclaimable memory slabs will be reclaimed
due to items being in use.
tmpfs has become much more widely used since distributions use it for
/tmp (Fedora 18+). In /proc/meminfo, memory used by tmpfs is accounted
into "Cached" (aka "NR_FILE_PAGES",
http://lxr.free-electrons.com/source/mm/shmem.c#L301 ).
The tools just pass it on, so what top, free and vmstat report as
"cached" is the sum of page cache and tmpfs.
free has the extremely useful "-/+ buffers/cache" output. However, now
that tmpfs is accounted into "cached", those numbers are way off once
you have big files in /tmp.
Fortunately, kernel 2.6.32 introduces "Shmem", which makes tmpfs memory
usage accessible from userspace (
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4b02108ac1b3354a22b0d83c684797692efdc395 ).
This patch substracts Shmem from Cached to get the actual page cache
memory. This makes both issues mentioned above disappear. For older
kernels, Shmem is not available (hence zero) and this patch is no-op.
Additionally:
* Update the man pages of free and vmstat to explain what is happening
* Finally drop "MemShared" from the /proc/meminfo parser, it has been
dead for 10+ years and is only causing confusion ( removed in kernel
2.5.54, see
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/?id=fe04e9451e5a159247cf9f03c615a4273ac0c571 )
procps automake defines restrict which means the binaries for procps
binaries compile. However external programs may not of defined
restrict which means they will not complie if they include files found
in /usr/include/proc.
Includes from libc6 use __restrict and if is good enough for
them, its good enough for us.
configure.ac now set to 3.3.1
vmstat -p has not worked for a long time, this applies Debian patch
vmstat_part_format, the details:
Author: Daniel Novotny
Description: The contents of /proc/diskstats have changed since 2.6.25
Changed PATH_MAX to 32 because its missing on hurd
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=485243
Bug-Debian: http://bugs.debian.org/588677
Last-Update: 2010-11-17
Library Changes
. added PROC_EDITCMDLCVT flag
. added an internal (static) fill_cmdline_cvt function:
- reads and "escapes" /proc/#/cmdline
- returns result as a single string in a single vector
- callers are guaranteed a cmdline (no more NULL)
. added vectorize_this_str function, exploited by
fill_cgroup_cvt, fill_cmdline_cvt
. generalized read_cmdline function as read_unvectored, now
exploited by fill_cgroup_cvt, fill_cmdline_cvt, read_cmdline
( cgroup and cmdline no longer need be converted to string )
( vectors before being transformed to final representation )
. fixed bug regarding skipped group numbers (when enabled)
. escape_str made responsible for all single byte translation
with distinction between control chars + other unprintable
. added escaped_copy function for already escaped strings
. reorganized parts of proc_t to restore formatting standards
( displacement changes shouldn't matter with new version # )
. former ZAP_SUSEONLY #define now OOMEM_ENABLE
. added to library.map: escaped_copy; read_cmdline
Top Program Changes
. exploited the new PROC_EDITCMDLCVT provision
. eliminated now obsolete #include "proc/escape.h"
. changed the P_WCH display format if no kernel symbol table
. fixed very old bug in lflgs for out-of-view sort fields
. former ZAP_SUSEONLY #define now OOMEM_ENABLE
Ps Program Changes
. exploited the new PROC_EDITCMDLCVT provision
. exploited the new escaped_copy function
. consolidated pr_args and pr_comm into pr_argcom
Signed-off-by: Jan Görig <jgorig@redhat.com>
Read the time of system boot from /proc/stat (entry: btime) instead
of computing it as the difference between the current time and the
uptime. This is the only way to get a consistent result which won't
possibly change from one run to the next.
The problems with the original code were:
* Both the current time and the uptime are rounded down to the second,
but the system doesn't boot on an integer second value so they do not
tick at the same moment. Thus, the rounding errors can cause a one
second difference from one run to the next.
* We can't read the uptime and the current time at the exact same moment
anyway, so the time difference we compute is bound to be inaccurate.
Bug-Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=222251
Author: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Craig Small <csmall@debian.org>
