summaryrefslogtreecommitdiffstats
path: root/include/memory
diff options
context:
space:
mode:
authorRik van Riel <riel@redhat.com>2014-01-21 15:49:05 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2014-01-21 16:19:43 -0800
commit34e431b0ae398fc54ea69ff85ec700722c9da773 (patch)
treea2a0de67b4cc754b5aa7627df3b0d1778d4cf10f /include/memory
parent5eaf1a9e233d61438377f57facb167f8208ba9fd (diff)
downloadop-kernel-dev-34e431b0ae398fc54ea69ff85ec700722c9da773.zip
op-kernel-dev-34e431b0ae398fc54ea69ff85ec700722c9da773.tar.gz
/proc/meminfo: provide estimated available memory
Many load balancing and workload placing programs check /proc/meminfo to estimate how much free memory is available. They generally do this by adding up "free" and "cached", which was fine ten years ago, but is pretty much guaranteed to be wrong today. It is wrong because Cached includes memory that is not freeable as page cache, for example shared memory segments, tmpfs, and ramfs, and it does not include reclaimable slab memory, which can take up a large fraction of system memory on mostly idle systems with lots of files. Currently, the amount of memory that is available for a new workload, without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low" watermarks from /proc/zoneinfo. However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory. It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place. Signed-off-by: Rik van Riel <riel@redhat.com> Reported-by: Erik Mouw <erik.mouw_2@nxp.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/memory')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud