Htydjtk

When running cat /proc/meminfo, you get these 3 values at the top:

MemTotal:        6291456 kB

MemFree:         4038976 kB

Cached:          1477948 kB

As far as I know, the "Cached" value is disk caches made by the Linux system that will be freed immediately if any application needs more RAM, thus Linux will never run out of memory until both MemFree and Cached are at zero.

Unfortunately, "MemAvailable" is not reported by /proc/meminfo, probably because it is running in a virtual server. (Kernel version is 4.4)

Thus for all practical purposes, the RAM available for applications is MemFree + Cached.

Is that view correct?

That view is outdated. The kernel now provides an estimate for available memory, in the MemAvailable field. This value is significantly different from MemFree + Cached.

/proc/meminfo: provide estimated available memory [kernel change description, 2014]

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.

...

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.

I expect the points about Cached / the page cache are the most noticeable ones, when you look at personal computers. Even in normal operation you can have a fair amount in tmpfs/shmem, and this cannot be reclaimed, it can only be moved to swap. This may even include some graphics memory allocations.

Whereas, the point about "lots of files" might not be relevant for many PC workloads. Even so, I currently have 500MB reclaimable slab memory on my laptop (out of 8GB of RAM). This is due to ext4_inode_cache (over 300K objects). It happened because I recently had to scan the whole filesystem, to find what was using my disk space :-). I used the command df -x / | sort, but e.g. Gnome Disk Usage Analyzer would do the same thing.

Memory in control groups

So-called "Linux containers" are built up from namespaces, cgroups, and various other features according to taste :-). They may provide a convincing enough environment to run something almost like a full Linux system. Hosting services can build such containers and sell them as "virtual servers" :-).

Linux allows setting memory limits on processes inside a control group. So in that case, not all of your memory will be available to the application :-).

There are many differences between cgroup-v1 and cgroup-v2.

My laptop runs cgroup-v1. I can run cat /sys/fs/cgroup/memory/memory.stat. This includes total_shmem - shmem including tmpfs counts towards the limit. I guess total_rss - (total_cached - total_shmem) is non-reclaimable. Plus the file memory.kmem.usage_in_bytes, representing kernel memory including slabs. Although I'm not sure if memory.kmem.tcp.* is counted under memory.kmem.*, or independently. The cgroup-v1 document says it does not reclaim any slab memory when hitting the limit, and there is not a separate counter to view reclaimable slabs.

cgroup-v2 is different. I think the root (top-level) cgroup doesn't support memory accounting. cgroup-v2 still has a memory.stat file. All the fields sum over child cgroups, so you don't need to look for total_... fields. There is a file field, which means the same thing as cache. Surprisingly I don't see an overall field like rss inside memory.stat; I guess you would have to add up individual fields. There are separate stats for reclaimable and unreclaimable slab memory; I think a v2 cgroup is designed to reclaim slabs when it starts to run low on memory.

Linux does not virtualize /proc/meminfo, so that will show the "host" values. Or in a VPS, it will more likely be faked up by the specific container software to avoid confusion. How useful the fake values are will depend on that software.

systemd believes cgroup-v1 cannot be securely delegated e.g. to containers. I looked inside a systemd-nspawn container on my cgroup-v1 system. I can see the cgroup it has been placed inside, and the memory accounting on that. On the other hand the contained systemd does not set up the usual per-service cgroups for resource accounting. If memory accounting was not enabled inside this cgroup, I assume the container would not be able to enable it.

I assume if you're inside a cgroup-v2 container, it will look different to the root of a real cgroup-v2 system, and you will be able to see memory accounting for its top-level cgroup. Or if the cgroup you can see does not have memory accounting enabled, you will hopefully be delegated permission to enable memory accounting in systemd (or equivalent).