我们还需要Page Cache么?-阿里云开发者社区

开发者社区> 阿里云操作系统软件> 正文

我们还需要Page Cache么?

简介: 作者:齐江 杨艇艇 马涛

本文根据 https://lwn.net/Articles/712467/ 翻译改编而来。

随着3DX POINT相关技术的逐渐普及和推广,我们可以预见很快持久化内存(Persistent Memory)将会被使用得越来越多,同时也催生了Linux内核很多方面的革新,Matthew Wilcox的DAX就是其中非常著名的一个,这个东东可以让用户对于基于持久化内存的文件系统跳过页面缓存(Page Cache)直接访问文件系统,而Dave Chinner甚至预测有了DAX,我们将不再需要页面缓存了。这个从1995年开始存在于Linux内核并造福无数苍生的玩意难道要寿终正寝了么?作为DAX的始作俑者,Matthew Wilcox又是怎么认为的?让我们一起去听听他在今年linux.conf.au上的演讲。

缓存的重要性

首先计算机就是缓存的世界,君不见体系结构领域里面关于cache相关的paper一直是层出不穷,此起彼伏。Wilcox甚至回过头查阅了1975年发行的Unix第六版,并在那里找到了使用缓冲区缓存的例子。同时Wilcox举例说只要缓存都命中,他的新电脑每秒可以执行100亿条指令。但是内存每秒只能跑5亿3千万条cache line,因此缓存未命中就会严重影响性能。如果数据没有缓存到主存,需要从存储设备读, 即使是快速的SSD,也会变得很慢。 PDP-11会因缓存未命中而显著变慢,几十年过去了,这个问题反而恶化了。因为CPU的发展速度比内存快,而同时内存的发展速度相比存储也更快,所以缓存未命中的带来的性能损失也会越来越严重。

什么是Linux的页面缓存

如前文所述,很久以来,Unix系统都有缓冲区缓存(Buffer Cache),位于文件系统与磁盘之间,目的是为了缓存磁盘块到内存中。Linux从一开始就有个缓冲区缓存。在1995年发行的1.3.50版本中,Linus Torvald做了一个重大创新——页面缓存。页面缓存与缓冲区缓存的区别在于,它是位于虚拟文件系统(VFS)与文件系统本身之间。有了页面缓存,如果所需的页面已经存在,则根本无需调用文件系统的代码。起初,页面缓存和缓冲区缓存是完全独立的,在1999年,Ingo Molnar统一了它们。现在,缓冲区缓存仍然存在,但是内容是指向页面缓存。

页面缓存有许多非常重要的功能,比如可以通过给定的索引查找页面。如果页面不存在,则创建并从磁盘填充相应的内容。脏页可以刷回磁盘,页面可以被锁定,解锁,以及从缓存中删除。线程可以等待页面状态的变化,也可以通过接口对给定状态的页面进行搜索,页面缓存还能够追踪与外部存储相关的错误等等。

另外页面缓存还需要有一套手段来对未来的使用进行预测。当缓存增长太大时,各种启发算法开始决策哪些页面应当被移除。仅使用了一次的页面很可能不会被再使用,因此它们将保留在“不活跃”链表(inactive list)并相对较快的换出。第二次使用将会把页面从不活跃链表转移到活跃链表(active list),活跃链表的页也会因为超时而被移到不活跃列表。 有一个例外,“影子”条目用于追踪已脱离不活跃链表并已回收的页面,这些条目可以延长相对遥远的过去使用过的页的生命周期。

随着内存变大,大页和透明大页也开始普及起来。不过透明大页(THP)特性最初只能用于匿名(非文件后端)内存,把大页在页面缓存中使用同样也会有很多优点。不过由于radix tree的限制,将大页作为页面缓存是Linux内核的一个挑战。最早的一个尝试是简单地往页面缓存中增加了大量单页条目,以对应于单个大页。Wilcox认为这种方法是“愚蠢的”,他增强了用于追踪页面缓存中页面的radix tree代码,使得页面缓存可以使用单个条目来表示对应的大页,从而使radix tree能够直接处理大页的条目。

是否仍然需要页面缓存?

介绍完页面缓存光辉的历史和强大的功能以后,我们回到开头的问题,现在Linux内核是否还需要页面缓存呢?由于Wilcox的DAX实现,Dave Chinner预测我们将不再需要页面缓存。当然同样也有其他人不同意Chinner,Linus Torvalds也是其中之一。Torvalds在一个单独的论坛中指出页面缓存很重要,因为在数据访问的关键路径上,好的东西从来不是出自低层的文件系统代码(译者作为一个文件系统开发者,表示很受伤,附上文中Torvalds的原话:the page cache is important because good things don’t come from having low-level filesystem code in the critical path for data access)。

对于是否需要页面缓存,DAX的作者Wilcox是咋想的呢?他说“没有什么比你的同事怀疑你的整个动机更糟糕的了”,所以貌似他也不是想干掉页面缓存。但是等等,为啥Dave Chinner会得出与之相反的结论呢?

原来Wilcox在设计他的DAX代码的时候,其实真的没有使用页面缓存。当一个应用使用类似于read()的系统调用从存储在持久化内存中的文件中读取数据时,DAX会介入。由于请求的数据不存在于页面缓存中,VFS层调用文件系统特定的read_iter()函数。这反过来调用到DAX代码,它将回调到文件系统将文件偏移转换为块号,然后查询块层以获取持久化内存块的位置(如果需要,将其映射到内核地址空间),最终使得块内容可以被拷贝回应用。

但是现在Wilcox觉得当初他的这个设计是错误的,read()应该以另外一种方式工作,初始的步骤是相同的,因为read_iter()函数仍将被调用,同时它将调用到DAX代码。但是,DAX不是回调到文件系统,而是应当调用到页面缓存以获取文件中所需偏移关联的物理地址,然后数据从该地址拷贝到用户空间。这样的逻辑就和现在页面缓存的工作原理完全一致了,而且如果信息已经存在页面缓存中的情况下,低层文件系统的代码完全无需介入。

Wilcox在这里又再次引用了Torvalds关于页面缓存的帖子:

从锁的角度来看,这也是一个重大的灾难:相信我,如果你认为你的文件系统可以进行细粒度的锁,当诸如并发路径查找的事情到来时,你会生活在一个梦幻世界。

Torvalds先生的话是“如此正确”,Wilcox说。DAX中的锁实现的确是灾难性的。他最初认为可能用相对简单的锁来解决,但复杂性在每个新发现的边缘场景蔓延。DAX的锁实现现在“实在丑陋”,他很抱歉他犯了一个错误,认为可以绕过页面缓存。现在,他说他必须去弥补这个错误。

未来的工作

Wilcox同时总结了围绕DAX和页面缓存的一系列增强。前文提到的大页支持优化是其中之一,这已经在mm树中,应该很快就可以完成。使用页框数而不是页面也已经讨论了一段时间,因为让内核为这些大型持久化内存保持大量的页面结构体(struct page)是完全没有必要的。

另外他想重新考虑文件系统块尺寸大于系统页面尺寸的想法,这是人们多年想要的东西。现在既然页面缓存可以处理多个页面大小,这个想法应该已经有希望了。不过他自己没时间折腾这个,所以他正在找寻其他感兴趣的开发人员一起来做这个项目。

交换大页也是一个不错的领域。我们已经在内存中使用了大页,但当这些大页被换出时,他们又被分解成普通尺寸的页面。针对这一问题,目前已经有一些提升交换性能的工作在进行,但是这个解法从根上来看可能就是不对的,正确的解法应该是让交换出去的大页保持在一起。相应的,这同样也有助于我们将内存交换到持久化内存。因为使用持久化内存的交换空间中的数据仍然可以被访问,因此将其留在那可能是有意义的,尤其是当数据没有被大量修改的时候。

最后附上Wilcox的演讲视频,视频中还包含了页面缓存锁的相关分析和讨论。

结论

所以貌似即使我们有了持久化内存,页面缓存还会继续存在下去。但是译者觉得随着持久化内存速度越来越快,价格越来越便宜,也许内核社区会有一些新的想法也说不定,让我们拭目以待吧。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

分享阿里云Linux及操作系统软件的生态、技术、产品、实践经验等。

官方博客
官网链接