free 命令是Linux系统上查看内存使用状况最常用的工具，然而很少有人能说清楚 “buffers” 与 “cached” 之间的区别：

我们先抛出结论，如果你对研究过程感兴趣可以继续阅读后面的段落：

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

下面是分析过程：

先用 strace 跟踪 free 命令，看看它是如何计算 “buffers” 和 “cached” 的：

显然 free 命令是从 /proc/meminfo 中读取信息的，跟我们直接读到的结果一样：

那么 /proc/meminfo 中的 “Buffers” 和 “Cached” 又是如何得来的呢？这回没法偷懒，只能去看源代码了。源代码文件是：fs/proc/meminfo.c ，我们感兴趣的函数是：meminfo_proc_show()，阅读得知：

“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 来查看，表示所有缓存页的总数量：

注意以上nr_file_pages是以page为单位（一个page等于4KB），而free命令是以KB为单位的。

直接修改 nr_file_pages 的内核函数是：
__inc_zone_page_state(page, NR_FILE_PAGES) 和
__dec_zone_page_state(page, NR_FILE_PAGES)，
一个用于增加，一个用于减少。

Swap Cache是什么？

用户进程的内存页分为两种：file-backed pages（与文件对应的内存页）和anonymous pages（匿名页）。匿名页(anonymous pages)是没有关联任何文件的，比如用户进程通过malloc()申请的内存页，如果发生swapping换页，它们没有关联的文件进行回写，所以只能写入到交换区里。

交换区可以包括一个或多个交换区设备（裸盘、逻辑卷、文件都可以充当交换区设备），每一个交换区设备在内存里都有对应的swap cache，可以把swap cache理解为交换区设备的”page cache”：page cache对应的是一个个文件，swap cache对应的是一个个交换区设备，kernel管理swap cache与管理page cache一样，用的都是radix-tree，唯一的区别是：page cache与文件的对应关系在打开文件时就确定了，而一个匿名页只有在即将被swap-out的时候才决定它会被放到哪一个交换区设备，即匿名页与swap cache的对应关系在即将被swap-out时才确立。

并不是每一个匿名页都在swap cache中，只有以下情形之一的匿名页才在：

• 匿名页即将被swap-out时会先被放进swap cache，但通常只存在很短暂的时间，因为紧接着在pageout完成之后它就会从swap cache中删除，毕竟swap-out的目的就是为了腾出空闲内存；
  【注：参见mm/vmscan.c: shrink_page_list()，它调用的add_to_swap()会把swap cache页面标记成dirty，然后它调用try_to_unmap()将页面对应的page table mapping都删除，再调用pageout()回写dirty page，最后try_to_free_swap()会把该页从swap cache中删除。】
• 曾经被swap-out现在又被swap-in的匿名页会在swap cache中，直到页面中的内容发生变化、或者原来用过的交换区空间被回收为止。
  【注：当匿名页的内容发生变化时会删除对应的swap cache，代码参见mm/swapfile.c: reuse_swap_page()。】

“cached”：

“Cached” 表示除去 “buffers” 和 “swap cache” 之外，剩下的也就是普通文件的缓存页的数量：
global_page_state(NR_FILE_PAGES) – total_swapcache_pages – i.bufferram
所以关键还是要理解 “buffers” 是什么含义。

“buffers” ：

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

这段代码的意思是遍历所有的块设备(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”。我们下面看看kernel中哪些地方会把块设备的mapping传递进来。

首先是块设备本身，打开时使用 bdev->bd_inode->i_mapping。

其次，文件系统的Superblock也是使用块设备：

sb表示SuperBlock，s_bdev就是块设备。Superblock是文件系统的metadata（元数据），不属于文件，没有对应的inode，所以，对metadata操作所涉及的缓存页都只能利用块设备mapping，算入 buffers 的统计值内。

如果文件含有间接块(indirect blocks)，因为间接块也属于metadata，所以走的也是块设备的mapping。查看源代码，果然如此：

这样我们就知道了”buffers” 是块设备(block device)占用的缓存页，分为两种情况：

• 直接对块设备进行读写操作；
• 文件系统的metadata（元数据），比如 SuperBlock。

验证：

现在我们来做个测试，验证一下上述结论。既然文件系统的metadata会用到 “buffers”，我们用 find 命令扫描文件系统，观察 “buffers” 增加的情况：

再测试一下直接读取block device，观察”buffers”增加的现象：

 结论：

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

ping常被用来测试网络延迟，但是有时ping的延迟并不是网络引起的，所以为了正确理解ping的结果，有必要了解影响ping延迟的几个因素。

ping的原理是通过发送ICMP echo request包，在收到ICMP echo reply包之后，计算发送时间与接收时间之间的差值，得出延迟的时间。ping的输出举例如下：

ping缺省每秒发一个echo request，发包的时候不会输出任何信息，直至收到echo reply的时候才输出一条信息，格式如上，最后一列是延迟时间，ms表示毫秒。

影响ping延迟的因素主要有：

ping延迟包含了进程调度的延迟

由于ping本身是用户态的程序，它首先会受到进程调度的影响，比方说高优先级的进程与ping争抢CPU的话，ping的执行就会遭到拖延，这个调度延迟如果是发生在发包之后、收包之前，就会被计入ping的延迟之中。

多个同时运行的ping进程之间会互相干扰，导致延迟

ping通过raw socket发送和接收ICMP包，而raw socket不仅会收到给自己的包，也会收到给别人的包，假如有多个ping进程同时在运行，你的ping就有可能会收到别人的ping的echo reply，当然，ping程序可以从中挑出给自己的包，因为包里嵌入了对应的ping进程号，但是每个包都打开看看、并判断是不是给自己的——这都要消耗时间的，所以说，多个ping进程之间会互相干扰，导致延迟加大。不同的UNIX版本由于实现方式的差异，受这个因素的影响程度也不一样，比如HP-UX受影响较大，而Linux受影响相对较小，因为Linux采用了一种过滤机制：Linux Socket Filtering，亦即Berkeley Packet Filter (BPF)，ping程序利用BPF给raw socket加上一个过滤器，这样内核会只把对应的echo reply传递给ping程序，给其他ping进程的echo reply不会再传给这个ping，避免了CPU和buffer资源的浪费，也减少了ping延迟。

其他类型的ICMP包也会对ping造成干扰

ICMP包有好几种类型，ping希望收到的是ICMP_ECHOREPLY，但是其他类型的包也都会传递给ping，我们上面说过，这是因为ping使用raw socket的缘故，raw socket会看到所有的ICMP包。ping需要消耗额外的时间和资源去查看这些本来不相干的包，故而有可能会产生延迟。以下列出各种ICMP包的类型供参考：

ICMP_ECHO
ICMP_ECHOREPLY
ICMP_SOURCE_QUENCH
ICMP_REDIRECT
ICMP_DEST_UNREACH
ICMP_TIME_EXCEEDED
ICMP_PARAMETERPROB

 注1：在Linux上，虽然ping采用了BPF过滤机制，但是只过滤掉了发给其他ping进程的ICMP_ECHOREPLY包，其他类型的包是不过滤的，所以仍然会受到影响。
注2：在HP-UX上ICMP_SOURCE_QUENCH是最常见的影响ping延迟的因素。Source Quench是一种简陋的流控机制，当接收端有缓冲区满的时候，通过向发送端返回Source Quench，告知发送端降低发送速度，而满溢的缓冲区不一定与ICMP有关，更常见的事UDP的缓冲区。由于这种机制存在种种问题，有许多反对使用Source Quench的声音，比如：RFC6633。Linux从2.2起就不再支持ICMP Source Quench了。

还有些其它因素，比如网卡驱动，防火墙软件什么的，但比较少见，就不深入探讨了。

怎样判断ping延迟是网络延迟还是其它因素导致的呢？

如果有1秒以上的延迟的话，观察一下icmp_seq，它表示包的顺序，在下例中，第3个包的延迟是2.068秒，而第4个包的延迟只有0.183秒，如果发包的频率严格保持每秒一次的话，第4个包应该比第3个包先收到才对，而下例中，包的顺序并未颠倒，这说明第4个包的发送也被延迟了。发送延迟，那就不是网络延迟了，肯定有其它原因。

还有一个简单的方法可以一试，ping一下127.0.0.1或者ping本机的IP地址，它们不用通过网络，甚至不用进入网卡驱动程序，所以延迟应该非常小，可以作为一个基准值，如果它们的延迟比较大，那最大的可能是存在调度延迟或者ICMP包干扰之类的问题。