在Arch 3.6.7 x86_64内核上，我试图说明系统的内存使用情况，我看得越多，似乎就越有漏洞（在使用内存的核算中，不存在漏洞）。的用法）。
这是一个新启动的系统。除了systemd和sshd之外，没有太多的运行可以保持简单
$ ps aux | sort -n -k6
...
root 316 0.0 0.0 7884 812 tty1 Ss+ 14:37 0:00 /sbin/agetty --noclear tty1 38400
matt 682 0.0 0.0 24528 820 pts/0 S+ 15:09 0:00 sort -n -k6
dbus 309 0.0 0.0 17280 1284 ? Ss 14:37 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
matt 681 0.0 0.0 10808 1364 pts/0 R+ 15:09 0:00 ps aux
root 308 0.0 0.0 26060 1516 ? Ss 14:37 0:00 /usr/lib/systemd/systemd-logind
root 148 0.0 0.0 25972 1692 ? Ss 14:37 0:00 /usr/lib/systemd/systemd-udevd
matt 451 0.0 0.0 78180 2008 ? S 14:37 0:00 sshd: matt@pts/0
root 288 0.0 0.0 39612 2708 ? Ss 14:37 0:00 /usr/sbin/sshd -D
matt 452 0.0 0.0 16452 3248 pts/0 Ss 14:37 0:00 -bash
root 1 0.0 0.0 32572 3268 ? Ss 14:37 0:00 /sbin/init
root 299 0.0 0.0 69352 3604 ? Ss 14:37 0:00 /usr/sbin/syslog-ng -F
root 449 0.0 0.0 78040 3800 ? Ss 14:37 0:00 sshd: matt [priv]
root 161 0.0 0.0 358384 9656 ? Ss 14:37 0:00 /usr/lib/systemd/systemd-journald
最详细的内存信息，我能找到的是这个从2007年这似乎已导致除PSS的领域一般内核占一个过程的，但他们的Python代码是老版本的内核，不幸的是一些在/ proc / K *文件从那以后消失了。在的/ proc / meminfo中的文件也是有帮助的，但老化有点太。
因此，展示了我所看到的。
# cat /proc/meminfo
MemTotal: 16345780 kB
MemFree: 16129940 kB
Buffers: 10360 kB
Cached: 48444 kB
SwapCached: 0 kB
Active: 24108 kB
Inactive: 46724 kB
Active(anon): 12104 kB
Inactive(anon): 3616 kB
Active(file): 12004 kB
Inactive(file): 43108 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 11996 kB
Mapped: 16372 kB
Shmem: 3696 kB
Slab: 25092 kB
SReclaimable: 11716 kB
SUnreclaim: 13376 kB
KernelStack: 928 kB
PageTables: 2428 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8172888 kB
Committed_AS: 34304 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 372788 kB
VmallocChunk: 34359362043 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 12288 kB
DirectMap2M: 16680960 kB
如果我们把用过的加起来：
MemTotal - MemFree - Buffers - Cached = Used
16345780 - 16129940 - 10360 - 48444 = 157036
所有的Active * / Inactive *似乎都是应用于某些页面（不是全部）的计数器，因此可以重复在其他页面上计数的内容。
Active + Inactive = Used
46724 + 24108 = 70832 (not quite)
这里的Commited_AS似乎与/ proc / * / smaps中共享空间折扣的用户空间私有/共享内存的总和紧密跟踪。考虑PSS也会排队。（出于兴趣，我在32位debian 2.6.32-5-686上获得了更大得多的Commited_AS）
AnonPages + Mapped + Commited_AS = Userspace?
11996 + 16372 + 34304 = 62672
Slab与/ proc / slabinfo内联
Slab + Shmem + KernelStack + PageTables = Kernelspace?
25092 + 3696 + 928 + 2428 = 32144
Userspace? + Kernelspace? = Used?
62672 + 32144 = 94816
所以〜63M短。令我惊讶的是，内核和所有加载的模块都缺少一些MB。平板似乎覆盖了很多，所以如果有任何遗漏，我不确定这是否等于〜60Mb？
63有点接近Active + Inactive数字，但是感觉不对。
有人知道魔术公式吗？否则，如果我正在查看的图形是正确的图形，那么可以在其中分配内存的灰色区域是什么？
看来linux吃了我的内存！尽管比通常指责的=）小
edit Commited_AS是内核估算的，它需要多少内存才能覆盖已提交内容的99.9％，因此不是实际分配的数字。AnonPages + Mapped是其中的一个组件，因此留下了一个较大的漏洞，现在大约有100MB。
User + Kernel
28368 + 32144 = 60512 != 157036
AnonPages和Mapped主要跟踪来自/ proc / [0-9] * / smaps wgen的anon /映射信息，并考虑了PSS / Shared。
保留区似乎全部适合从总内存中取出的块：
总free内存为16345032Kb
系统总内存为16777216Kb
PCI'孔' lspci -v -266520K = 16510696K
Bios保留dmesg -92793K = 16417903K
edit2
我注意到，额外的内存使用不是在原盒中运行的VM上/proc/meminfo。所以我开始四处看看，看看两者之间有什么不同。最终发现可用总物理内存的增加与已用内存的增加同时发生。
phys 16GB used>144508 vm>50692 user>21500 kern>26428 u+ktot>47928
vm 64MB used>24612 vm>31140 user>14956 kern>14440 u+ktot>29396
vm 256MB used>26316 vm>35260 user>14752 kern>14780 u+ktot>29532
vm 1GB used>33644 vm>35224 user>14936 kern>14772 u+ktot>29708
vm 2GB used>41592 vm>35048 user>14736 kern>15056 u+ktot>29792
vm 4GB used>57820 vm>35232 user>14780 kern>14952 u+ktot>29732
vm 8GB used>82932 vm>36912 user>15700 kern>15388 u+ktot>31088
vm 12GB used>110072 vm>35248 user>14812 kern>15624 u+ktot>30436
vm 15GB used>122012 vm>35424 user>14832 kern>15824 u+ktot>30656
得出的结果是，每1GB内存分配约8Mb的内存。可能是内核中的内存映射...但是我认为这只会随着分配的内存而增加，而不是在启动时设置。
如果这种趋势持续下去，看看是否有人可以使用bigmem机器会很有趣吗？
ps。在中的整体用法/proc/meminfo。唯一的过程记帐是通过smaps进行的，它考虑了共享内存和私有内存，但这仅是与meminfo中的AnonPages / Mapped值进行比较。
ps在于设计。不要将其用于内存记帐。