/proc/meminfoの値はどのように計算されますか？

/!\現在の状態: アップデート 4 /!\

一部の/proc/meminfo値は、他の値の合計または違いです。ただし、これら2つのリンクには計算方法の説明はあまりありません（ctrl-fを押すだけです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)

他のフィールドに関する多くの情報が見つかりませんでした。

• /proc/meminfoでMemTotalを計算する方法 (2035272kB対予想2034284kB)
• /proc/meminfoのエントリ

これら2つの値が正しく計算されましたか？それとも、外部の手段によって若干の変化がありますか？

また、一部の値は外部値なしでは明らかに計算できませんが、まだ興味があります。

値はどのように/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しかし、私はコーダーではないので、これらの列挙型（inなど）とグローバル変数（totalram_pagesfrom si_meminfoinなど）を特定するのは困難です。page_alloc.c#L4673）いっぱい。

アップデート2:

これで列挙部分が確認されていNR_LRU_LISTSます5。

しかし、このtotalram_pages部分は見つけるのが難しいようです...

アップデート3:

コードが複雑すぎて見えて読めないようです。誰かがこれを行い、/proc/meminfo価値がどのように計算されるかを示したら、彼/彼女は賞金を得ることができます。

回答が詳細になるほど、賞金が高くなります。

アップデート4:

1年半が経過した後、この問題の原因の1つが実際に2019年8月についに発見された悪名高いOOM（Out of Memory）のバグに関連していることがわかりました。最低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を正しく報告しません。

また、次の関連質問に回答がある可能性があります。

• RAMの30％は「バッファ」です。それは何ですか？

• 上部の「buff / cache」フィールドと「avail mem」フィールドはどういう意味ですか？

• ディストリビューションで移植可能な使用可能なメモリ量を取得するには？

/proc/meminfoしたがって、価値を取得する方法に関する「アップデート3」のポイントはまだ有効です。

しかし、、次のリンクからOOMの問題についてのより多くの洞察を得ることができ、いくつかのGUIで提供される非常に有望なプロジェクトについても議論します！ :https://github.com/hakavlad/nohang

私が行った最初のテストでは、このnohangツールは実際に約束したとおりですearlyoom。