如何计算/proc/meminfo值？

Question

/!\当前状态:更新4/！

一些/proc/meminfo值是其他值的和或差。然而，对于如何在这两个链接中计算这些链接(只需执行ctrl meminfo以达到这个目的)，并没有太多的说明：

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

此外，我还到处挖，到目前为止我发现的是：

MemFree:              LowFree + HighFree
Active:               Active(anon) + Active(file)
Inactive:             Inactive(anon) + Inactive(file)

关于其他字段，我没有发现太多，在我的位置上，结果并不匹配，就像在这些Stack溢出帖子中：

• 如何计算/proc/meminfo中的MemTotal (2035272 kB与预期的2034284 kB)
• 输入/proc/meminfo - on堆栈溢出

这两个值计算正确吗？或者是由于某种外部手段而产生的变异？

而且，有些值--很明显--在没有外部值的情况下是无法计算的，但我仍然对此感兴趣。

如何计算/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等)和全局变量(例如，si_meminfo in 页面_alloc.c#L4673中的totalram_pages )是在哪里填充的。

更新2

枚举部分现在解决了，NR_LRU_LISTS等于5。

但totalram_pages部分似乎更难找出.

更新3

看起来我看不懂这段代码，因为它看上去很复杂。如果有人设法做到这一点，并展示了如何计算/proc/meminfo价值，他/她可以得到赏金。

答案越详细，赏金就越高。

更新4

一年半后，我了解到，这个问题的原因之一实际上是一个非常臭名昭著的OOM (内存不足)错误，它终于在2019年8月在至少16年的"wontfix“之后被识别出来，直到某个著名的Linux家伙(再次感谢你，Artem S Tashkinov！:)使非elitst Linux社区的声音‘终于听到了：是的，Linux在桌面上的内存/内存压力很低的情况下是不好的。

而且，大多数Linux发行版确实更精确地计算了实际可用的RAM，主要是从2017年开始(在这个问题发生时还没有更新我的发行版)，尽管内核修复程序在3.14 (2014年3月)中登陆，这也提供了一些更多的线索：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

但是，OOM问题在2021年仍然存在，即使在某些边缘修复(earlyoom和systemd-oomd)中发生的频率确实较低，而计算出的可用内存仍然没有正确地报告实际使用的内存。

此外，这些相关问题可能有一些答案：

• 内存的30%是“缓冲区”。那是什么？
• 在顶部的“buff/cache”和“mem”字段意味着什么？
• 如何获得跨发行版可移植的可用内存量？

因此，我在“更新3”中关于/proc/meminfo如何获取其值的观点仍然有效。

然而，对于下一个链接的OOM问题有更深入的了解，它也讨论了一个非常有前途的项目，它甚至还附带了一些GUI !：https://github.com/hakavlad/nohang。

我所做的第一次测试似乎表明，这个nohang工具似乎确实做到了它所承诺的，甚至比earlyoom更好。

Answer 1

/proc/meminfo的含量由meminfo_proc_show在……里面fs/proc/meminfo.c在内核中测定。

计算都比较简单，但所使用的信息来源并不一定那么明显。例如，MemTotal是来自sysinfo结构的totalram值；由si_meminfo在……里面mm/page_alloc.c填充。