0

Since a few years the kernel, and userland tools can show available mem, which should be a better proxy for actual free usable memory, however, the following does not make sense to me:

top - 23:47:56 up 13 days,  7:48,  1 user,  load average: 0.06, 0.64, 0.62
Tasks: 450 total,   1 running, 245 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.1 sy,  0.0 ni, 99.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 65804776 total, 40605824 free, 17817976 used,  7380976 buff/cache
KiB Swap:  2097148 total,  2097148 free,        0 used. 60642008 avail Mem 

A total of 64GiB, minus actual memory in use of > 16GiB, can never result in an available memory of 60GB, can it?

/update

cat /proc/meminfo 
MemTotal:       65804776 kB
MemFree:        40606636 kB
MemAvailable:   60643028 kB
Buffers:         5519324 kB
Cached:          1411404 kB
SwapCached:            0 kB
Active:          7135492 kB
Inactive:       16794208 kB
Active(anon):    3674000 kB
Inactive(anon):     1176 kB
Active(file):    3461492 kB
Inactive(file): 16793032 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB
Dirty:               288 kB
Writeback:             0 kB
AnonPages:      16999208 kB
Mapped:           316332 kB
Shmem:              1872 kB
Slab:             722784 kB
SReclaimable:     450364 kB
SUnreclaim:       272420 kB
KernelStack:       17616 kB
PageTables:        44752 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    34999536 kB
Committed_AS:   23735028 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      600688 kB
DirectMap2M:    17063936 kB
DirectMap1G:    51380224 kB

2

For the documentation of /proc:

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.

Note that it is an estimate.

In the particular example given in the question, observe the huge value of the Inactive(file) field, 16,793,032 KiB; this is pagecache memory which has not been used recently and is considered to be immediately reclaimable without a large performance impact. Added to the 40,606,636 KiB of unused memory, this already gives 57,399,668 KiB of memory which can be immediately allocated to satisfy new requests. The system considers that it can also discard some other bits and pieces (mostly the Active(file), pagecache memory which is backed by files on disk, so that it can be be re-read if necessary), so that overall is estimates that is can satisfy a request for 60,643,028 KiB of memory.

| improve this answer | |
  • Your answer makes sense, however, in my case the RSS of the top 8 processes alone sums up to 16G, does that mean that RSS includes pagecache? – hbogert Oct 30 '19 at 10:35
  • @hbogert: RSS is a "narrow" (= from the point of view of a process) view. /proc/meminfo gives a "global" view (= from the point of view of the kernel). Yes, RSS includes virtual memory pages (for example, code segments) which are backed by disk files and thus can be discarded. – AlexP Oct 30 '19 at 14:52
  • What function, on C-level, would I need to invoke to create a high RSS which is backed by disk files? I thought RSS can never be revoked/discarded by the kernel, only paged out to disk. – hbogert Oct 30 '19 at 14:58
  • (1) RSS includes code segments. (2) mmap() is an example of a function which may increase your RSS while still backed by a disk file. – AlexP Oct 30 '19 at 15:01
  • Looking further at the processes which use a lot, >16GB is marked 'anon' by the pmap program, i.e., not backed by file. It still doesn't add up that the kernel counts a large portion of that 16GB as available. – hbogert Oct 30 '19 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.