Linux Kernel中AEP的现状和发展

发表于 2019-05-13 14:06:52 收藏 已收藏
赞(0) •  评论(0

Linux Kernel中AEP的现状和发展

发表于 2019-05-13 14:06:52
+关注

AEP简介

AEP是Intel推出的一种新型的非易失Optane Memory设备,又被称作Apache Pass,所以一般习惯称作AEP。在这之前也有类似的设备称作NVDIMM或PMEM,目前Linux创建的AEP设备节点也是叫做pmem(如/dev/pmem0),所以本文中NVDIMM或PMEM都指AEP。但是本文不是为了科普AEP,如果想了解AEP的一些基本知识,可以参考以下几篇文章:NVDIMM Enabling in SUSE Linux Enterprise Part 1NVDIMM Enabling in SUSE Linux Enterprise Part 2Persistent Memory Wiki

Linux Kernel中AEP的现状和发展

DAX

目前Linux Kernel中主要把PMEM看成一个类似于磁盘的块设备,所以可以在PMEM设备上创建文件系统,使它看起来和一般的磁盘没什么区别。但是设备的具体物理属性完全不一样,比如读写的latency,PMEM可以达到和DRAM接近的程度,磁盘当然是望尘莫及的。所以,这就带来一个问题,众所周知,一般在Linux上常见的文件系统,比如ext4,xfs等,都是给磁盘设计的,都用到了page cache来缓存磁盘上的数据来提高性能。但是,对于PMEM设备来说,它的访问延迟已经和内存接近了,为什么还需要内存中的page cache呢?所以,目前Linux Kernel中对这一块最大的改进就是支持DAX(Direct Access)。一句话解释DAX,就是DAX bypass了page cache。无论读写都是直接操作PMEM上的数据。DAX需要在文件系统层面支持,如果要使用DAX,那么需要在mount文件系统时传入“-o dax”参数,比如:

1 /dev/pmem0 on /mnt type xfs (rw,relatime,seclabel,attr2,dax,inode64,noquota)

DAX极大地提高了文件系统在PMEM设备上的性能,但是还有一些问题没有解决,比如:1. 文件系统的metadata还是需要使用page cache或buffer cache。2. “-o dax”mount option是对整个文件系统的,不能做更细粒度的控制。3. 没有一个API来告诉应用访问的文件是不是可以DAX访问的。虽然DAX还有这些问题,但是目前DAX还是Linux Kernel中的主流使用方式。

PMEM用作NUMA node

既然PMEM就是memory,只是带宽和latency上差一点,那么自然会想到能不能就把PMEM当做memory用呢?答案当然是可以的。目前支持SRAT或者HMAT的硬件,都可以把PMEM识别为一个或多个NUMA node。Dave Hansen的这组patch,Allow persistent memory to be used like normal RAM,就是通过memory hotplug的方式把PMEM添加到Linux的buddy allocator里面。
       新添加的PMEM会以一个或多个NUMA node的形式出现,Linux Kernel就可以分配PMEM上的memory,这样和使用一般DRAM没什么区别。目前看这组patch已经没有什么blocking issues,不出什么问题的话,很快就会合并进入内核主线。但是,到这里只是解决了第一步的问题,怎么把PMEM“用好”的问题还没有解决。比如,当内核分配内存时,如果从PMEM上分配了memory,并且这块内存上的数据是被经常访问的,那么由于物理特性上的差异,一般应>用都会体会到性能的下降。那么怎么更明智的使用PMEM就是一个亟待解决的问题。
       吴峰光的一组patch,PMEM NUMA node and hotness accounting/migration,来尝试解决这个问题。这组patch主要提供了下面几个功能:1. 隔离DRAM和PMEM。为PMEM单独构造了一个zonelist,这样一般的内存分配是不会分配到PMEM上的。2. 跟踪内存的冷热。利用内核中已经有的idle page tracking功能(目前主线内核只支持系统全局的tracking),在per process的粒度上跟踪内存的冷热。3. 利用现有的page reclaim,在reclaim时将冷内存迁移到PMEM上(只能迁移匿名页)。4. 利用一个userspace的daemon和idle page tracking,来将热内存(在PMEM上的)迁移到DRAM中。这组patch发到LKML以后,引来了很激烈的讨论。
       主要集中在两个方面:
        1. 为什么要单独构造一个zonelist把PMEM和DRAM分开?其实在这块,我们也遇到了相似的问题。我们在某些项目要求做到控制每个进程使用的DRAM和PMEM的比例(比如8:2),但是目前的NUMA API做不到。目前的NUMA API只能控制从哪个node分配,但是不能控制比例,>比如mbind(),只能告诉进程这段VMA可以用哪些node,但是不能控制具体多少memory从哪个node来。要想做到更细粒度的控制,需要改造目前的NUMA API。而且目前memory hierarchy越来越复杂,比如device memory,这都是目前的NUMA API所不能很好解决的。
        2. 能不能把冷热内存迁移通用化?冷热内存迁移这个方向是没有问题的,问题在于目前patch中的处理太过于PMEM specific了。内核中的NUMA balancing是把“热”内存迁移到最近的NUMA node来提高性能。但是却没有对“冷”内存的处理。所以能不能实现一种更通用的NUMA rebalancing?比如,在reclaim时候,不是直接reclaim内存,而是把内存迁移到一个远端的,或者空闲的,或者低速的NUMA node,类似于NUMA balancing所做的,只不过是往相反的方向。笔者的一组patch,Another Approach to Use PMEM as NUMA Node,就体现了这种思路。利用Kernel中>已经很成熟的memory reclaim路径把“冷”内存迁移到PMEM node中,NUMA Balancing访问到这个page的时候可以选择是否把这个页迁移回DRAM,相当于是一种比较粗粒度的“热”内存识别。
        社区中还有一种更加激进的想法就是不区分PMEM和DRAM,在memory reclaim时候只管把“冷”内存迁移到最近的remote node,如果target node也有内存压力,那就在target node上做同样的迁移。但是这种方法有可能引入一个内存迁移“环”,导致内存在NUMA node中间不停地迁移,有可能引入unbounded time问题。而且一旦node增多,可能会迅速恶化问题。
        在笔者看来,在内存回收方面还有一个更可能立竿见影的方案就是把PMEM用作swap设备或者swap文件。目前swap的最大问题就是传统磁盘的延迟问题,很容易造成系统无响应,这也是为什么有zswap这样的技术出现。PMEM的低延迟特性完全可以消除swap的延迟问题。在这个方面,我们也正在做一些探索和实验。

PMEM用作RAM(DRAM作为Cache)

这个标题看起来有点歧义,上面已经说了PMEM可以作为NUMA node使用,这不已经是作为RAM了吗?怎么这里还要说用作RAM?这就涉及到AEP的另一个用法了,那就是所谓的“memory mode”。当在memory mode时,DRAM>并不是和PMEM并列的,而是变成了PMEM透明的Cache,PMEM就成了DRAM。这时候PMEM和DRAM的关系就变成了DRAM和Cache的关系。而且,DRAM是一个direct mapped的Cache(这点很重要)。这时疑问就来了,这样不是更没有什么可做的?既不需要管理NUMA,也没有冷热内存的问题了,热的自然就被Cache了。是的,但是这会引入另外一个问题,就是Cache冲突的问题。上面已经提到,在这种情况下,DRAM是一个direct mapped的Cache,就是在同样索引下只有一个cache line命中,这样会带来比较严重的Cache冲突问题,从而降低Cache的命中率,带来性能问题。对于这个问题的详细解释,请参见这篇文章为了解决这个Cache冲突的问题,Dan Williams提出了这组patch,mm: Randomize free memory。这组patch的想法很简单,就是通过randomize free area的方式来降低Cache>冲突。目前这组patch已经合并入-mm tree,不出意外应该会在5.1时合并入内核主线。但是这种配置的问题就是不够灵活,需要在BIOS中配置,一旦配置不可在运行时更改。

NVDIMM专用文件系统

前面提到PMEM可以作为一个块设备部署文件系统,但是现在支持的文件系统,比如ext4,xfs等,在设计时更多的考虑了怎样针对磁盘优化。但是PMEM是性质完全不同的存储介质,虽然经过一些改造,这些传统的文件系统可以比较好的工作在PMEM上,但是还是会有很多不适合PMEM的地方,比如metadata还要经过page cache等。所以,NVDIMM专用文件系统就应用而生了。

NOVA

NOVA Filesystem就是专门为PMEM设计的文件系统。笔者对文件系统研究不深,而且对NOVA也没有很深入的研究,所以就不在这里班门弄斧了。感兴趣的读者可以参考NOVA的github link之前,NOVA曾发到LKML上,但是好像社区里的maintainer们没有时间仔细review一个新的文件系统,所以合入社区的努力暂时停止了,但是还在github上继续开发中。

ZUFS

ZUFS是来自于NetApp的一个项目,ZUFS的意思是Zero-copy User Filesystem。声称是实现了完全的zero-copy,甚至文件系统的metadata都是zero-copy的。ZUFS主要是为了PMEM设计,但是也可以支持传统的磁盘设备,相当于是FUSE的zero-copy版本,是对FUSE的性能的提升。目前作者正在尝试将ZUFS的kernel部分upstream,据他说RHEL已经同意将ZUFS作为一个module加入RHEL 8。

收藏

相关话题

评论(0)

加载更多评论

分享到

QQ空间 QQ好友 微博
取消