Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
proc_sysinfo: Properly account for kb_main_shared
Linux "free" output has been improved and adapted over time. Already at some point in 2014-2016, the format changed in an incompatible way.[1] [1] https://askubuntu.com/questions/770108/what-do-the-changes-in-free-output-from-14-04-to-16-04-mean Ideally I would recommend "free" to users to view several fields, in particular: 1. "available" (requires not-ancient kernel) 2. swap usage 3. "shared". Often hundreds of megabytes on modern desktops. Excessive "shared" memory can help show/analyze a problem. This will detect if tmpfs is filling up the system RAM. Sometimes this detects a memory leak that does not show up in process resident memory. It has sometimes showed graphics allocations which are not being freed properly, including but not limited to GEM buffers. Sadly, two of the six columns were misleading. 1. "cache" - and hence "buff/cache" - includes "shared". But "shared" is not a reclaimable cache! It must be swapped instead. Linux handles it on the same LRU lists as anonymous memory. I am not able to explain why Cached included Shmem originally. I would love if Linux could change it! But... This "quirk" has also been enshrined in memory.stat - "cached" in cgroup-v1, and "file" in cgroup-v2. These statistics are documented & at the top of the list. I would not dare think to change them. The true knowledge about Cached in /proc/meminfo has now been spread by several articles since at least 2017. And if anyone had to compensate for this e.g. in their alert systems, the kernel ABI rules say they should not touch it. I fear it is too late now :'-(. They should just admit it, and fix all the meminfo docs to admit the quirk. Let us fix the "cache" column in "free". I think it will be nicer. The "free" docs did not admit the "quirk" either. On the bright side, at least when there was a problem, and you run "free -h", the excessive "shared" figure stood out. It was right next to the cached" figure that pretends there is no problem. I cannot imagine anyone mourning this quirk. 2. "used" In a previous version of "free", there were two separate lines, with the second line shown as "+- buffers/cache". In this version, "used" is always show as "+- buffers/cache". ...That's right, the entire value of "cached" was subtracted from "used", so that "used" no longer includes "shared". Now this might just be a personal irritant of mine. But, when I have to look at "free", I spend far too long re-discovering why the "used" value is *so* different from "total - available". I am not expecting it would match exactly: "total - available" should be higher, by up to 3 times the "low water mark"[2]. The margin from the "watermarks" is usually relatively small - only a few percentage points out of total system memory. [2] https://unix.stackexchange.com/questions/261247/how-can-i-get-the-amount-of-available-memory-portably-across-distributions Including "shared" in the "used" figure will avoid the specific neurosis I have :-). Making used ~= total - available will significantly simplify the output of "free". It will usually appear consistent with the single usage level shown in gnome-system-monitor. Community support is aware the "available" metric is the intended, modern, and reliable thing to look at.[3] [3] See e.g. https://www.linuxatemyram.com/ I believe these arguments sufficient, to justify changing the "used" value even if we did not change "cache". But given that we are changing the "cache" value, it is *essential* that we update the value previously known as "used +- buffers/cache". You can see this in the diff. I only modify the line calculating kb_main_cached. kb_main_used is already derived from kb_main_cached, so no further change is required.
- Loading branch information