X.L*_*INK 5 memory linux-kernel ram meminfo
/!\ 当前状态：更新 4 /!\
某些 /proc/meminfo 值是某些其他值的总和或差值。但是，关于如何在这两个链接中计算它们的说法不多（只需按 ctrl-fmeminfo即可到达）：
此外，我还到处挖掘，这是我迄今为止发现的：
MemFree: LowFree + HighFree
Active: Active(anon) + Active(file)
Inactive: Inactive(anon) + Inactive(file)
我没有找到太多关于其他领域的信息，在我有的地方，结果不匹配，就像在这些 Stack Overflow 帖子中一样：
这两个值计算正确吗？还是由于某些外部手段而存在一些可变性？
此外，某些值显然无法在没有外部值的情况下进行计算，但我仍然对此感兴趣。
/proc/meminfo数值是如何计算的？
如果这有帮助，这里有一个例子/proc/meminfo：
MemTotal: 501400 kB
MemFree: 38072 kB
MemAvailable: 217652 kB
Buffers: 0 kB
Cached: 223508 kB
SwapCached: 11200 kB
Active: 179280 kB
Inactive: 181680 kB
Active(anon): 69032 kB
Inactive(anon): 70908 kB
Active(file): 110248 kB
Inactive(file): 110772 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal:
HighFree:
LowTotal:
LowFree:
MmapCopy:
SwapTotal: 839676 kB
SwapFree: 785552 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 128964 kB
Mapped: 21840 kB
Shmem: 2488 kB
Slab: 71940 kB
SReclaimable: 41372 kB
SUnreclaim: 30568 kB
KernelStack: 2736 kB
PageTables: 5196 kB
Quicklists:
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1090376 kB
Committed_AS: 486916 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 4904 kB
VmallocChunk: 34359721736 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages:
ShmemPmdMapped:
CmaTotal:
CmaFree:
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 36800 kB
DirectMap2M: 487424 kB
DirectMap4M:
DirectMap1G:
更新 1：
这是用于/proc/meminfo填充其数据的代码：
http://elixir.free-electrons.com/linux/v4.15/source/fs/proc/meminfo.c#L46
然而，因为我不是一个编码器，我有一个很难弄清楚这些地方枚举（如NR_LRU_LISTS等）和全局变量（例如totalram_pages来自si_meminfo于page_alloc.c＃L4673）被填充。
更新2：
枚举部分现已解决，并且NR_LRU_LISTS等于5。
但是这totalram_pages部分似乎更难找到......
更新 3：
看起来我将无法阅读代码，因为它看起来很复杂。如果有人设法做到并展示了如何/proc/meminfo计算价值，他/她可以获得赏金。
答案越详细，赏金越高。
更新 4：
一年半之后，我了解到这个问题的一个原因实际上与臭名昭著的 OOM（内存不足）错误有关，该错误在经过至少 16 年的“ wontfix ”之后终于在 2019 年 8 月被识别出来，直到某个著名的 Linux 人（再次感谢你，Artem S Tashkinov！:)）让非精英 Linux 社区的声音终于听到：“是的，Linux 在桌面上的低 RAM/内存压力情况下表现不佳”。
此外，尽管内核修复程序在 3.14（2014 年 3 月）中登陆，但大多数 Linux 发行版确实更准确地计算了实际可用RAM，主要是自 2017 年左右（在提出此问题时尚未更新我的发行版），这也提供了更多线索：https : //git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/? id =34e431b0ae398fc54ea69ff85ec700722c9da773
但是，OOM 问题在 2021 年仍然存在，即使它确实发生的频率较低，但有些边界修复（earlyoom和systemd-oomd），而计算出的可用RAM 仍然没有正确报告实际使用的 RAM。
此外，这些相关问题可能有一些答案：
因此，我关于“更新 3”关于如何/proc/meminfo获取其值的观点仍然有效。
然而，在下一个链接上有更多关于 OOM 问题的见解，它也谈到了一个非常有前途的项目，它甚至带有一点图形用户界面！：https : //github.com/hakavlad/nohang
我所做的第一次测试似乎表明，这个nohang工具确实做到了它所承诺的，甚至比earlyoom.
的内容/proc/meminfo由内核meminfo_proc_show中的fs/proc/meminfo.cin决定。
计算都相对简单，但所使用的信息来源并不一定如此明显。例如，MemTotal是totalram来自sysinfo结构的值；由si_meminfoinmm/page_alloc.c填充。