☰

/proc/meminfo 值是如何计算的？

tag-icon • tag-icon linux-kernel memory ram meminfo
/proc/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_meminfoinpage_alloc.c#L4673) 已满。

更新2:

枚举部分现已解决，并且NR_LRU_LISTS等于5。

但这totalram_pages部分似乎更难找到......

更新3:

看起来我无法阅读代码，因为它看起来非常复杂。如果有人设法做到这一点并展示/proc/meminfo价值是如何计算的，他/她就可以获得赏金。

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

更新4:

一年半后，我了解到这个问题的原因之一实际上与臭名昭著的 OOM（内存不足）错误有关，该错误最终于 2019 年 8 月被认识到至少 16 年的 ”无法修复”，直到一些著名的 Linux 人（再次感谢你，Artem S Tashkinov！:)）让非精英 Linux 社区的声音终于被听到：“是的，Linux 在桌面上的低 RAM/内存压力情况下表现不佳”。

此外，大多数 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），这种情况发生的频率确实降低了（和），而计算得出的可用的RAM 仍然无法正确报告实际使用的 RAM。

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

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

然而，有关下一个链接中 OOM 问题的更多见解，其中还讨论了一个非常有前途的项目，它甚至还附带了一点 GUI！：https://github.com/hakavlad/nohang

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

答案1

的内容/proc/meminfo由下式决定meminfo_proc_show在fs/proc/meminfo.c内核中。

计算都相对简单，但所使用的信息来源不一定那么明显。例如，MemTotal是totalram来自sysinfo结构体的值；填写的是si_meminfo在mm/page_alloc.c。

相关内容