页高速缓存 address_space的问题

[小魔菇]

每个inode都有一个address_space对象？由该address_space来维护该inode所拥有的所有页缓存？
不知道我的理解是不是对的
如果是对的 那么每个inode都需要一个address_space对象，每个inode维护一个基树，开销岂不是很大？
还是系统维护一个大的基树，然后每个inode的基树都挂在上面？

请高手指点。

[deep_pro]

lz的理解很对
inode都有一个address_space对象,见inode的结构体定义，由该address_space来维护该inode所拥有的所有页缓存。
确实是每一个inode维护一个基树，这样在一个巨大文件中可以实现缓存页快速寻找

[小魔菇]

但是对小文件来说 每个文件都维护一个基树 得不偿失哦
在linux中有没有对小文件的页缓冲的机制？

[deep_pro]

lkd2上说
2.6以前的内核，页高速缓存是通过一个维护了系统所有的全局散列表进行检索，效率很低，
因为要用锁保护这么大的一片全局散列表，锁争用要更严重，同时散列表太大，但其实只需要跟当前文件相关的页，如果查找失败更糟糕，意味着需要遍历指定散列键值对应的整个链表。

这样看的话，“还是系统维护一个大的基树，然后每个inode的基树都挂在上面？ ”是不会被使用的方法
我不懂这个基树的算法有多牛x，至少比以前的散列表好
如果文件很小的话，基树也会很小，查找起来也更迅速

在linux中有没有对小文件的页缓冲的机制？
---------------
不知道啊

[小魔菇]

[Quote=引用 3 楼 deep_pro 的回复:]
lkd2上说
2.6以前的内核，页高速缓存是通过一个维护了系统所有的全局散列表进行检索，效率很低，
因为要用锁保护这么大的一片全局散列表，锁争用要更严重，同时散列表太大，但其实只需要跟当前文件相关的页，如果查找失败更糟糕，意味着需要遍历指定散列键值对应的整个链表。

这样看的话，“还是系统维护一个大的基树，然后每个inode的基树都挂在上面？ ”是不会被使用的方法
我不懂这个基树的算法有多牛x，至少比以前的散列表好
如果文件很小的话，基树也会很小，查找起来也更迅速

在linux中有没有对小文件的页缓冲的机制？
---------------
不知道啊
[/Quote]
也对啊
如果只用一棵树的话 文件过多 这棵树就太大了
还是分开比较好 速度快一些
是不是有点空间换时间的感觉 呵呵

[小魔菇]

突然又想到了一个问题
基树的节点上挂的是页的描述符
那页存放在哪儿呢？
应该存放在专门一个缓冲区里面对吧 基树只是一个用来快速查找的工具
ULK2上面也没怎么说清楚 或者是我没看清楚吧 呵呵