论坛徽章:: 16

电梯直达

1楼 [收藏(0)] [报告]

发表于 2012-06-02 16:32 |只看该作者 |倒序浏览

tao ma童鞋在他的blog中对这个buffer/cache进行了分析

http://blog.tao.ma/?p=10

下边是我的实验：

root@kernel:~# free
         total    used    free    shared buffers    cached
Mem:    2058704    626532 1432172       0    34028    275880
-/+ buffers/cache:    316624 1742080
Swap:    2093052       0 2093052
root@kernel:~# echo 3 > /proc/sys/vm/drop_caches
root@kernel:~# dd if=/dev/sda of=/dev/null bs=1M count=1000
记录了1000+0 的读入
记录了1000+0 的写出
1048576000字节(1.0 GB)已复制，17.8285 秒，58.8 MB/秒
root@kernel:~# free
         total    used    free    shared buffers    cached
Mem:    2058704 1417524    641180       0    750016    295728
-/+ buffers/cache:    371780 1686924
Swap:    2093052       0 2093052

为什么buffer从33.2MB变成了732.4MB?
看那个代码意思应该是把所有块设备的设备文件的大小加到一起，这700MB哪里来的？

文库|博客

firkraag

家境小康

论坛徽章:: 1

2楼 [报告]

发表于 2012-06-02 19:01 |只看该作者

回复 1# embeddedlwp
不是块设备文件的大小，而是块设备address_space基树中拥有的页面的数量。

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

tempname2

富足长乐

论坛徽章:: 2

3楼 [报告]

发表于 2012-06-02 21:46 |只看该作者

不是很明白怎么得到这个数值的。

buffer page，从现在的实现上来说，是建立于裸block device的page cache之上的一种cache机制。纯粹用page cache的话，一个cache单位是由file + page offset标识的。但文件系统有时需要得到某个block device的某个block，这时根本没有文件的概念，需要使用另一种disk cache，即buffer cache，其中一个cache单位由block device + block number来标识。

早期的disk cache只有buffer cache，每次想读block device:block number时，首先看看buffer cache里有没有，没有则先把目标数据读到buffer cache里；写则直接写到buffer cache，期待下次读或写时能直接操作buffer cache里的数据。page cache是后来发展出来抽象层次更高的cache机制。2.4时两种cache共存，2.6里则将buffer cache建立于page cache之上。

读一般文件时，只要一页的内容在磁盘上是连续的，数据就直接进了page cache；如果不是连续的，则将算出各个block在块设备上的page offset，将这些page带进raw块设备文件的page cache，再获取其中有用的部分。如果直接读写raw块设备文件，理论上来说，相当于读写一个数据在磁盘上完全连续的文件，应该可以认为，此时像读写一般连续文件一样，数据全部进了raw块设备的page cache里，但这个page cache却被视为构建buffer cache之处，当作buffer page处理了。最后的结果，却是跟有意生成buffer cache（显式通过buffer接口读取一个block）或者无意生成buffer cache（读写某文件在磁盘上不连续的一页），效果是一样的。