页高速缓存 address_space的问题

小魔菇 2010-01-13 03:22:58

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

请高手指点。

...全文

267 5 打赏收藏转发到动态举报

写回复

用AI写文章

5 条回复

切换为时间正序

请发表友善的回复…

发表回复

小魔菇 2010-01-13

打赏
举报

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

小魔菇 2010-01-13

打赏
举报

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

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

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

deep_pro 2010-01-13

打赏
举报

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

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

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

小魔菇 2010-01-13