内存"丢失"

 

根据 free 以及top 命令发现问题如下：

used内存占用很大，而实际系统中个进程并没有占用这么多内存， 同时cache/buffer 使用非常小，对于used内存，将近有15g的内存不知道被什么给使用？

先google 看下 meminfo 各个字段的含义：

参考：http://linuxperf.com/?cat=7不保证是对的！

MemTotal

系统从加电开始到引导完成，firmware/BIOS要保留一些内存，kernel本身要占用一些内存，最后剩下可供kernel支配的内存就是MemTotal

MemFree

表示系统尚未使用的内存。[MemTotal-MemFree]就是已被用掉的内存。

　　追踪Linux系统的内存使用一直是个难题，很多人试着把能想到的各种内存消耗都加在一起，kernel text、kernel modules、buffer、cache、slab、page table、process RSS…等等，
却总是与物理内存的大小对不上，这是为什么呢？因为Linux kernel并没有滴水不漏地统计所有的内存分配，kernel动态分配的内存中就有一部分没有计入/proc/meminfo中。

我们知道，Kernel的动态内存分配通过以下几种接口：

• alloc_pages/__get_free_page: 以页为单位分配
• vmalloc: 以字节为单位分配虚拟地址连续的内存块
• slab allocator
  •  　　kmalloc: 以字节为单位分配物理地址连续的内存块，它是以slab为基础的，使用slab层的general caches — 大小为2^n，名称是kmalloc-32、kmalloc-64等（在老kernel上的名称是size-32、size-64等）。

通过slab层分配的内存会被精确统计，可以参见/proc/meminfo中的slab/SReclaimable/SUnreclaim；
通过vmalloc分配的内存也有统计，参见/proc/meminfo中的VmallocUsed 和 /proc/vmallocinfo

　　通过alloc_pages分配的内存不会自动统计，除非调用alloc_pages的内核模块或驱动程序主动进行统计，否则我们只能看到free memory减少了，
但从/proc/meminfo中看不出它们具体用到哪里去了

　　内核所用内存的静态部分，比如内核代码、页描述符等数据在引导阶段就分配掉了，并不计入MemTotal里，而是算作Reserved(在dmesg中能看到)。而内核所用内存的动态部分，
是通过上文提到的几个接口申请的，其中通过alloc_pages申请的内存有可能未纳入统计，就像黑洞一样

1.1 SLAB

通过slab分配的内存被统计在以下三个值中：

• SReclaimable: slab中可回收的部分。调用kmem_getpages()时加上SLAB_RECLAIM_ACCOUNT标记，表明是可回收的，计入SReclaimable，否则计入SUnreclaim。
• SUnreclaim: slab中不可回收的部分。
• Slab: slab中所有的内存，等于以上两者之和。

1.2 VmallocUsed

　　通过vmalloc分配的内存都统计在/proc/meminfo的 VmallocUsed 值中，但是要注意这个值不止包括了分配的物理内存，还统计了VM_IOREMAP、VM_MAP等操作的值，
譬如VM_IOREMAP是把IO地址映射到内核空间、并未消耗物理内存，所以我们要把它们排除在外。从物理内存分配的角度，我们只关心VM_ALLOC操作，
这可以从/proc/vmallocinfo中的vmalloc记录看到
/proc/vmallocinfo中能看到vmalloc来自哪个调用者(caller)，那是vmalloc()记录下来的，相应的源代码可见：

mm/vmalloc.c: vmalloc > __vmalloc_node_flags > __vmalloc_node > __vmalloc_node_range > __get_vm_area_node > setup_vmalloc_vm

 
通过vmalloc分配了多少内存，可以统计/proc/vmallocinfo中的vmalloc记录:

grep vmalloc /proc/vmallocinfo | awk '{total+=$2}; END {print total}'

1.3 kernel modules (内核模块)

　　系统已经加载的内核模块可以用 lsmod 命令查看，注意第二列就是内核模块所占内存的大小，通过它可以统计内核模块所占用的内存大小，但这并不准，因为”lsmod”列出的是[init_size+core_size]，
而实际给kernel module分配的内存是以page为单位的，不足 1 page的部分也会得到整个page，此外每个module还会分到一页额外的guard page

lsmod
Module Size Used by
veth 13410 0
xt_nat 12681 5
ipt_MASQUERADE 12678 4
nf_nat_masquerade_ipv4 13412 1 ipt_MASQUERADE
nf_conntrack_netlink 40449 0
xt_addrtype 12676 2 

　　lsmod的信息来自/proc/modules，它显示的size包括init_size和core_size，
我们可以在 /sys/module/<module-name>/ 目录下分别看到coresize和initsize的值

　　因为给kernel module分配内存是以page为单位的，不足 1 page的部分也会得到整个page，此外，每个module还会分到一页额外的guard page。
而”lsmod”列出的是[init_size+core_size]，比实际分配给kernel module的内存小
kernel module所占用的内存包含在/proc/vmallocinfo的统计之中，不必再去计算”lsmod”的结果了，而且”lsmod”也不准。

1.5 PageTables

　　Page Table用于将内存的虚拟地址翻译成物理地址，随着内存地址分配得越来越多，Page Table会增大，/proc/meminfo中的PageTables统计了Page Table所占用的内存大小。
　　注：请把Page Table与Page Frame（页帧）区分开，物理内存的最小单位是page frame，每个物理页对应一个描述符(struct page)，在内核的引导阶段就会分配好、保存在mem_map[]数组中，mem_map[]所占用的内存被统计在dmesg显示的reserved中，/proc/meminfo的MemTotal是不包含它们的。（在NUMA系统上可能会有多个mem_map数组，在node_data中或mem_section中）。
　　而Page Table的用途是翻译虚拟地址和物理地址，它是会动态变化的，要从MemTotal中消耗内存。

1.6 KernelStac

　　每一个用户线程都会分配一个kernel stack（内核栈），内核栈虽然属于线程，但用户态的代码不能访问，只有通过系统调用(syscall)、自陷(trap)或
异常(exception)进入内核态的时候才会用到，也就是说内核栈是给kernel code使用的。在x86系统上Linux的内核栈大小是固定的8K或16K
Kernel stack（内核栈）是常驻内存的，既不包括在LRU lists里，也不包括在进程的RSS/PSS内存里，所以我们认为它是kernel消耗的内存。统计值是/proc/meminfo的KernelStack。

2. 用户进程

/proc/meminfo统计的是系统全局的内存使用状况，单个进程的情况要看/proc/<pid>/下的smaps等等。

2.1 Hugepages

　　Hugepages在/proc/meminfo中是被独立统计的，与其它统计项不重叠，既不计入进程的RSS/PSS中，又不计入LRU Active/Inactive，也不会计入cache/buffer。
如果进程使用了Hugepages，它的RSS/PSS不会增加。

　　注：不要把 Transparent HugePages (THP)跟 Hugepages 搞混了，THP的统计值是/proc/meminfo中的”AnonHugePages”，在/proc/<pid>/smaps中也有单个进程的统计，
这个统计值与进程的RSS/PSS是有重叠的，如果用户进程用到了THP，进程的RSS/PSS也会相应增加，这与Hugepages是不同的。
Hugepages是独立统计的，如果进程使用了Hugepages，它的RSS/PSS不会增加。下面举例说明，一个进程通过mmap()申请并使用了Hugepages，
在/proc/<pid>/smaps中可以看到如下内存段，VmFlags包含的”ht”表示Hugepages，kernelPageSize是2048kB，注意RSS/PSS都是0

2.2 AnonHugePages

　　AnonHugePages统计的是Transparent HugePages (THP)，THP与Hugepages不是一回事，区别很大。
Hugepages在/proc/meminfo中是被独立统计的，与其它统计项不重叠，既不计入进程的RSS/PSS中，又不计入LRU Active/Inactive，也不会计入cache/buffer。
　　如果进程使用了Hugepages，它的RSS/PSS不会增加。
而AnonHugePages完全不同，它与/proc/meminfo的其他统计项有重叠，首先它被包含在AnonPages之中，而且在/proc/<pid>/smaps中也有单个进程的统计，
与进程的RSS/PSS是有重叠的，如果用户进程用到了THP，进程的RSS/PSS也会相应增加，这与Hugepages是不同的

2.3 LRU

LRU是Kernel的页面回收算法(Page Frame Reclaiming)使用的数据结构，在解读vmstat中的Active/Inactive memory一文中有介绍。
Page cache和所有用户进程的内存（kernel stack和huge pages除外）都在LRU lists上。
LRU lists包括如下几种，在/proc/meminfo中都有对应的统计值：

• LRU_INACTIVE_ANON – 对应 Inactive(anon)
• LRU_ACTIVE_ANON – 对应 Active(anon)
• LRU_INACTIVE_FILE – 对应 Inactive(file)
• LRU_ACTIVE_FILE – 对应 Active(file)
• LRU_UNEVICTABLE – 对应 Unevictable

注：
　　Inactive list里的是长时间未被访问过的内存页，Active list里的是最近被访问过的内存页，LRU算法利用Inactive list和Active list可以判断哪些内存页可以被优先回收。
括号中的 anon 表示匿名页(anonymous pages)。
　　用户进程的内存页分为两种：file-backed pages（与文件对应的内存页），和anonymous pages（匿名页），比如进程的代码、映射的文件都是file-backed，而进程的堆、
栈都是不与文件相对应的、就属于匿名页。file-backed pages在内存不足的时候可以直接写回对应的硬盘文件里，称为page-out，不需要用到交换区(swap)；
　　而anonymous pages在内存不足时就只能写到硬盘上的交换区(swap)里，称为swap-out。
　　括号中的 file 表示 file-backed pages（与文件对应的内存页）。
　　Unevictable LRU list上是不能pageout/swapout的内存页，包括VM_LOCKED的内存页、SHM_LOCK的共享内存页（又被统计在”Mlocked”中）、和ramfs。
在unevictable list出现之前，这些内存页都在Active/Inactive lists上，vmscan每次都要扫过它们，但是又不能把它们pageout/swapout，
这在大内存的系统上会严重影响性能，设计unevictable list的初衷就是避免这种情况，参见：https://www.kernel.org/doc/Documentation/vm/unevictable-lru.txt

LRU与/proc/meminfo中其他统计值的关系：

• LRU中不包含HugePages_*。
• LRU包含了 Cached 和 AnonPages。

2.4 Shmem

/proc/meminfo中的Shmem统计的内容包括：

shared memory
tmpfs和devtmpfs。
　　注：所有tmpfs类型的文件系统占用的空间都计入共享内存，devtmpfs是/dev文件系统的类型，/dev/下所有的文件占用的空间也属于共享内存。
可以用ls和du命令查看。如果文件在没有关闭的情况下被删除，空间仍然不会释放，shmem不会减小，可以用 “lsof -a +L1 /<mount_point>” 命令列出这样的文件

　　因为shared memory在内核中都是基于tmpfs实现的，参见：
https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
　　也就是说它们被视为基于tmpfs文件系统的内存页，既然基于文件系统，就不算匿名页，所以不被计入/proc/meminfo中的AnonPages，而是被统计进了：

Cached (i.e. page cache)
　　Mapped (当shmem被attached时候)然而它们背后并不存在真正的硬盘文件，一旦内存不足的时候，它们是需要交换区才能swap-out的，所以在LRU lists里，

它们被放在：Inactive(anon) 或 Active(anon)
　　注：虽然它们在LRU中被放进了anon list，但是不会被计入 AnonPages。这是shared memory & tmpfs比较拧巴的一个地方，需要特别注意。
或 unevictable （如果被locked的话）
注意：当shmget/shm_open/mmap创建共享内存时，物理内存尚未分配，要直到真正访问时才分配。/proc/meminfo中的 Shmem 统计的是已经分配的大小，而不是创建时申请的大小。

2.5 AnonPages

　　前面提到用户进程的内存页分为两种：file-backed pages（与文件对应的内存页），和anonymous pages（匿名页）。Anonymous pages(匿名页)的数量统计在/proc/meminfo的AnonPages中。

以下是几个事实，有助于了解Anonymous Pages：

所有page cache里的页面(Cached)都是file-backed pages，不是Anonymous Pages。”Cached”与”AnoPages”之间没有重叠。
注：shared memory 不属于 AnonPages，而是属于Cached，因为shared memory基于tmpfs，所以被视为file-backed、在page cache里，上一节解释过。
mmap private anonymous pages属于AnonPages(Anonymous Pages)，而mmap shared anonymous pages属于Cached(file-backed pages)，因为shared anonymous mmap也是基于tmpfs的，上一节解释过。
Anonymous Pages是与用户进程共存的，一旦进程退出，则Anonymous pages也释放，不像page cache即使文件与进程不关联了还可以缓存。
AnonPages统计值中包含了Transparent HugePages (THP)对应的 AnonHugePages

2.6 Mapped

　　上面提到的用户进程的file-backed pages就对应着/proc/meminfo中的”Mapped”。

Page cache中(“Cached”)包含了文件的缓存页，其中有些文件当前已不在使用，page cache仍然可能保留着它们的缓存页面；

而另一些文件正被用户进程关联，比如shared libraries、可执行程序的文件、mmap的文件等，这些文件的缓存页就称为mapped。
/proc/meminfo中的”Mapped”就统计了page cache(“Cached”)中所有的mapped页面。”Mapped”是”Cached”的子集。
因为Linux系统上shared memory & tmpfs被计入page cache(“Cached”)，所以被attached的shared memory、以及tmpfs上被map的文件都算做”Mapped”。

进程所占的内存页分为anonymous pages和file-backed pages，理论上应该有：
【所有进程的PSS之和】 == 【Mapped + AnonPages】。

2.7 Cached

Page Cache里包括所有file-backed pages，统计在/proc/meminfo的”Cached”中。

　　Cached是”Mapped”的超集，就是说它不仅包括mapped，也包括unmapped的页面，当一个文件不再与进程关联之后，原来在page cache中的页面并不会立即回收，仍然被计入Cached，还留在LRU中，但是 Mapped 统计值会减小。【ummaped = (Cached – Mapped)】
Cached包含tmpfs中的文件，POSIX/SysV shared memory，以及shared anonymous mmap。
注：POSIX/SysV shared memory和shared anonymous mmap在内核中都是基于tmpfs实现的，参见：https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
“Cached”和”SwapCached”两个统计值是互不重叠的，源代码参见下一节。所以，Shared memory和tmpfs在不发生swap-out的时候属于”Cached”，
而在swap-out/swap-in的过程中会被加进swap cache中、属于”SwapCached”，一旦进了”SwapCached”，就不再属于”Cached”了。

2.8 Buffers

　　“Buffers”表示块设备(block device)所占用的缓存页，包括：直接读写块设备、以及文件系统元数据(metadata)比如SuperBlock所使用的缓存页。

它与“Cached”的区别在于，”Cached”表示普通文件所占用的缓存页

“Buffers”所占的内存同时也在LRU list中，被统计在Active(file)或Inactive(file)。

注：通过阅读源代码可知，块设备的读写操作涉及的缓存被纳入了LRU，以读操作为例，

do_generic_file_read()函数通过 mapping->a_ops->readpage() 调用块设备底层的函数，并调用 add_to_page_cache_lru() 把缓存页加入到LRU list中。参见：

filemap.c: do_generic_file_read > add_to_page_cache_lru

kernel内存的统计方式应该比较明确，即

• 【Slab+ VmallocUsed + PageTables + KernelStack + HardwareCorrupted + Bounce + X】
• VmallocUsed其实不是我们感兴趣的，因为它还包括了VM_IOREMAP等并未消耗物理内存的IO地址映射空间，我们只关心VM_ALLOC操作;

grep vmalloc /proc/vmallocinfo | awk '{total+=$2}; END {print total}' 为统计此处操作

• kernel module的内存被包含在VmallocUsed中
• X表示直接通过alloc_pages/__get_free_page分配的内存，没有在/proc/meminfo中统计，不知道有多少，就像个黑洞

应用层内存统计：

　　围绕RSS/PSS进行统计
把/proc/[1-9]*/smaps 中的 Pss 累加起来就是所有用户进程占用的内存，但是还没有包括Page Cache中unmapped部分、以及HugePages，所以公式如下：

ΣPss + (Cached – mapped) + Buffers + (HugePages_Total * Hugepagesize)

系统内存的使用情况可以用以下公式表示：

• MemTotal = MemFree +【Slab+ VmallocUsed + PageTables + KernelStack + HardwareCorrupted + Bounce + X】+【Active + Inactive + Unevictable + (HugePages_Total * Hugepagesize)】
• MemTotal = MemFree +【Slab+ VmallocUsed + PageTables + KernelStack + HardwareCorrupted + Bounce + X】+【Cached + AnonPages + Buffers + (HugePages_Total * Hugepagesize)】
• MemTotal = MemFree +【Slab+ VmallocUsed + PageTables + KernelStack + HardwareCorrupted + Bounce + X】+【ΣPss + (Cached – mapped) + Buffers + (HugePages_Total * Hugepagesize)】

“buffers” 表示块设备(block device)所占用的缓存页，包括：直接读写块设备、以及文件系统元数据(metadata)比如SuperBlock所使用的缓存页；
“cached” 表示普通文件数据所占用的缓存页。

“Cached” 来自于以下公式：

• global_page_state(NR_FILE_PAGES) – total_swapcache_pages – i.bufferram

global_page_state(NR_FILE_PAGES) 表示所有的缓存页(page cache)的总和，它包括：

• “Cached”
• “Buffers” 也就是上面公式中的 i.bufferram，来自于 nr_blockdev_pages() 函数的返回值。
• 交换区缓存(swap cache)

global_page_state(NR_FILE_PAGES) 来自 vmstat[NR_FILE_PAGES]，vmstat[NR_FILE_PAGES] 可以通过 /proc/vmstat 来查看，表示所有缓存页的总数量：
“cached”：“Cached” 表示除去 “buffers” 和 “swap cache” 之外，剩下的也就是普通文件的缓存页的数量：

global_page_state(NR_FILE_PAGES) – total_swapcache_pages – i.bufferram

所以关键还是要理解 “buffers” 是什么含义。
“buffers” ：

//从源代码中看到，”buffers” 来自于 nr_blockdev_pages() 函数的返回值：

long nr_blockdev_pages(void)
{
struct block_device *bdev;
long ret = 0;
spin_lock(&bdev_lock);
list_for_each_entry(bdev, &all_bdevs, bd_list) {
ret += bdev->bd_inode->i_mapping->nrpages;
}
spin_unlock(&bdev_lock);
return ret;
}

　　遍历所有的块设备(block device)，累加每个块设备的inode的i_mapping的页数，统计得到的就是 buffers。显然 buffers 是与块设备直接相关的。

那么谁会更新块设备的缓存页数量(nrpages)呢？我们继续向下看。

搜索kernel源代码发现，最终更新mapping->nrpages字段的函数就是：

pagemap.h: add_to_page_cache
> filemap.c: add_to_page_cache_locked
> __add_to_page_cache_locked
> page_cache_tree_insert

 
和：

filemap.c: delete_from_page_cache
> __delete_from_page_cache
> page_cache_tree_delete

　　block device 和 文件inode 都可以调用，至于更新的是块设备的(buffers)还是文件的(cached)，取决于参数变量mapping：
如果mapping对应的是块设备，那么相应的统计信息会反映在 “buffers” 中；

如果mapping对应的是文件inode，影响的就是 “cached”

怎样统计所有进程总共占用多少内存？

　　RSS(resident set size)表示常驻内存的大小，但是由于不同的进程之间会共享内存，所以把所有进程RSS进行累加的方法会重复计算共享内存，得到的结果是偏大的
正确的方法是累加 /proc/[1-9]*/smaps 中的 Pss 。/proc/<pid>/smaps 包含了进程的每一个内存映射的统计值，详见proc(5)的手册页。
Pss(Proportional Set Size)把共享内存的Rss进行了平均分摊，
　　比如某一块100MB的内存被10个进程共享，那么每个进程就摊到10MB。这样，累加Pss就不会导致共享内存被重复计算了

cat /proc/[1-9]*/smaps | grep Pss |awk '{total += $2 }; END{print total}'

 在回到一开始的问题：Linux的内存都用到哪里去了？

 　　目前看应该是 被alloc_pages 分配使用，由于当时环境没有看到， 只有一个top  free meminfo 结果图， dmesg 信息没看到，ps 统计其rss 结果也很少。所以最后也无从查证了

ps：

sar参数说明
-A 汇总所有的报告
-a 报告文件读写使用情况
-B 报告附加的缓存的使用情况
-b 报告缓存的使用情况
-c 报告系统调用的使用情况
-d 报告磁盘的使用情况
-g 报告串口的使用情况
-h 报告关于buffer使用的统计数据
-m 报告IPC消息队列和信号量的使用情况
-n 报告命名cache的使用情况
-p 报告调页活动的使用情况
-q 报告运行队列和交换队列的平均长度
-R 报告进程的活动情况
-r 报告没有使用的内存页面和硬盘块
-u 报告CPU的利用率
-v 报告进程、i节点、文件和锁表状态
-w 报告系统交换活动状况
-y 报告TTY设备活动状况

man proc 结果为：

 /proc/meminfo
              This  file reports statistics about memory usage on the system.  It is used by free(1) to report the amount of free and used memory (both physical and swap) on the system as well as
              the shared memory and buffers used by the kernel.  Each line of the file consists of a parameter name, followed by a colon, the value of the parameter, and an option  unit  of  mea‐
              surement  (e.g.,  "kB").  The list below describes the parameter names and the format specifier required to read the field value.  Except as noted below, all of the fields have been
              present since at least Linux 2.6.0.  Some fileds are displayed only if the kernel was configured with various options; those dependencies are noted in the list.

              MemTotal %lu
                     Total usable RAM (i.e. physical RAM minus a few reserved bits and the kernel binary code).

              MemFree %lu
                     The sum of LowFree+HighFree.

              Buffers %lu
                     Relatively temporary storage for raw disk blocks that shouldn't get tremendously large (20MB or so).

              Cached %lu
                     In-memory cache for files read from the disk (the page cache).  Doesn't include SwapCached.

              SwapCached %lu
                     Memory that once was swapped out, is swapped back in but still also is in the swap file.  (If memory pressure is high, these pages don't need to be swapped out again  because
                     they are already in the swap file.  This saves I/O.)

              Active %lu
                     Memory that has been used more recently and usually not reclaimed unless absolutely necessary.

              Inactive %lu
                     Memory which has been less recently used.  It is more eligible to be reclaimed for other purposes.

              Active(anon) %lu (since Linux 2.6.28)
                     [To be documented.]

              Inactive(anon) %lu (since Linux 2.6.28)
                     [To be documented.]

              Active(file) %lu (since Linux 2.6.28)
                     [To be documented.]

              Inactive(file) %lu (since Linux 2.6.28)
                     [To be documented.]

              Unevictable %lu (since Linux 2.6.28)
                     (From Linux 2.6.28 to 2.6.30, CONFIG_UNEVICTABLE_LRU was required.)  [To be documented.]

              Mlocked %lu (since Linux 2.6.28)
                     (From Linux 2.6.28 to 2.6.30, CONFIG_UNEVICTABLE_LRU was required.)  [To be documented.]

              HighTotal %lu
                     (Starting  with  Linux  2.6.19,  CONFIG_HIGHMEM  is required.)  Total amount of highmem.  Highmem is all memory above ~860MB of physical memory.  Highmem areas are for use by
                     user-space programs, or for the page cache.  The kernel must use tricks to access this memory, making it slower to access than lowmem.

              HighFree %lu
                     (Starting with Linux 2.6.19, CONFIG_HIGHMEM is required.)  Amount of free highmem.

              LowTotal %lu
                     (Starting with Linux 2.6.19, CONFIG_HIGHMEM is required.)  Total amount of lowmem.  Lowmem is memory which can be used for everything that highmem can be used for, but it  is
                     also  available  for the kernel's use for its own data structures.  Among many other things, it is where everything from Slab is allocated.  Bad things happen when you're out
                     of lowmem.

              LowFree %lu
                     (Starting with Linux 2.6.19, CONFIG_HIGHMEM is required.)  Amount of free lowmem.

              MmapCopy %lu (since Linux 2.6.29)
                     (CONFIG_MMU is required.)  [To be documented.]

              SwapTotal %lu
                     Total amount of swap space available.

              SwapFree %lu
                     Amount of swap space that is currently unused.

              Dirty %lu
                     Memory which is waiting to get written back to the disk.

              Writeback %lu
                     Memory which is actively being written back to the disk.

  AnonPages %lu (since Linux 2.6.18)
                     Non-file backed pages mapped into user-space page tables.

              Mapped %lu
                     Files which have been mmaped, such as libraries.

              Shmem %lu (since Linux 2.6.32)
                     [To be documented.]

              Slab %lu
                     In-kernel data structures cache.

              SReclaimable %lu (since Linux 2.6.19)
                     Part of Slab, that might be reclaimed, such as caches.

              SUnreclaim %lu (since Linux 2.6.19)
                     Part of Slab, that cannot be reclaimed on memory pressure.

              KernelStack %lu (since Linux 2.6.32)
                     Amount of memory allocated to kernel stacks.

              PageTables %lu (since Linux 2.6.18)
                     Amount of memory dedicated to the lowest level of page tables.

              Quicklists %lu (since Linux 2.6.27)
                     (CONFIG_QUICKLIST is required.)  [To be documented.]

              NFS_Unstable %lu (since Linux 2.6.18)
                     NFS pages sent to the server, but not yet committed to stable storage.

              Bounce %lu (since Linux 2.6.18)
                     Memory used for block device "bounce buffers".

              WritebackTmp %lu (since Linux 2.6.26)
                     Memory used by FUSE for temporary writeback buffers.

              CommitLimit %lu (since Linux 2.6.10)
                     Based on the overcommit ratio ('vm.overcommit_ratio'), this is the total amount of  memory currently available to be allocated on the system.  This limit is adhered  to  only
                     if strict overcommit accounting is enabled (mode 2 in /proc/sys/vm/overcommit_ratio).  The CommitLimit is calculated using the following formula:
 CommitLimit = (overcommit_ratio * Physical RAM) + Swap

                     For example, on a system with 1GB of physical RAM and 7GB of swap with a overcommit_ratio of 30, this formula yields a CommitLimit of 7.3GB.  For more details, see the memory
                     overcommit documentation in the kernel source file Documentation/vm/overcommit-accounting.

              Committed_AS %lu
                     The amount of memory presently allocated on the system.  The committed memory is a sum of all of the memory which has been allocated by processes, even if  it  has  not  been
                     "used"  by  them  as  of yet.  A process which allocates 1GB of memory (using malloc(3) or similar), but touches only 300MB of that memory will show up as using only 300MB of
                     memory even if it has the address space allocated for the entire 1GB.  This 1GB is memory which has been "committed" to by the VM and can be used at any time by the  allocat‐
                     ing  application.   With strict overcommit enabled on the system (mode 2 /proc/sys/vm/overcommit_memory), allocations which would exceed the CommitLimit (detailed above) will
                     not be permitted.  This is useful if one needs to guarantee that processes will not fail due to lack of memory once that memory has been successfully allocated.

              VmallocTotal %lu
                     Total size of vmalloc memory area.

              VmallocUsed %lu
                     Amount of vmalloc area which is used.

              VmallocChunk %lu
                     Largest contiguous block of vmalloc area which is free.

              HardwareCorrupted %lu (since Linux 2.6.32)
                     (CONFIG_MEMORY_FAILURE is required.)  [To be documented.]

              AnonHugePages %lu (since Linux 2.6.38)
                     (CONFIG_TRANSPARENT_HUGEPAGE is required.)  Non-file backed huge pages mapped into user-space page tables.

              HugePages_Total %lu
                     (CONFIG_HUGETLB_PAGE is required.)  The size of the pool of huge pages.

              HugePages_Free %lu
                     (CONFIG_HUGETLB_PAGE is required.)  The number of huge pages in the pool that are not yet allocated.

              HugePages_Rsvd %lu (since Linux 2.6.17)
                     (CONFIG_HUGETLB_PAGE is required.)  This is the number of huge pages for which a commitment to allocate from the pool has been made, but no  allocation  has  yet  been  made.
                     These reserved huge pages guarantee that an application will be able to allocate a huge page from the pool of huge pages at fault time.
    HugePages_Surp %lu (since Linux 2.6.24)
                     (CONFIG_HUGETLB_PAGE  is  required.)   This is the number of huge pages in the pool above the value in /proc/sys/vm/nr_hugepages.  The maximum number of surplus huge pages is
                     controlled by /proc/sys/vm/nr_overcommit_hugepages.

              Hugepagesize %lu
                     (CONFIG_HUGETLB_PAGE is required.)  The size of huge pages.