Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MemAvailable value in /proc/meminfo #16

Closed
briand-icabbi opened this issue Oct 5, 2016 · 1 comment
Closed

MemAvailable value in /proc/meminfo #16

briand-icabbi opened this issue Oct 5, 2016 · 1 comment
Milestone

Comments

@briand-icabbi
Copy link

In Linux kernel release 3.14 a new metric has been introduced in “/proc/meminfo” called "MemAvailable".

https://www.kernel.org/doc/Documentation/filesystems/proc.txt

MemAvailable: An estimate of how much memory is available for starting new
              applications, without swapping. Calculated from MemFree,
              SReclaimable, the size of the file LRU lists, and the low
              watermarks in each zone.
              The estimate takes into account that the system needs some
              page cache to function well, and that not all reclaimable
              slab will be reclaimable, due to items being in use. The
              impact of those factors will vary from system to system.

Further details in the original commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

MemAvailable details the amount of memory that is available for a new workload without the need for swapping. In the past it was possible to calculate this figure by adding the "MemFree" and "Cached" values together, however this is is pretty much guaranteed to be wrong in systems running Kernels since 3.14.

Could this be added? The Slab allocation in the Linux Kernel tends to be higher giving inaccurate values in MemFree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants