Linux Kernel中AEP的现状和发展
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
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/pmem0on/mnttypexfs(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。
DTR8510变压器匝比测试仪的功能特点及应用范围
串口屏如何把同一个工程快速转换为不同分辨率工程
低功耗AI芯片加持摄像头 边缘设备智能化是安防新趋势
2019年Q1季度全球TOP10半导体芯片设计公司榜单公布 TOP5公司除了联发科其他全数衰退
“发现和合成量子点”斩获诺奖 晶能光电积极融入显示产业变革
Linux Kernel中AEP的现状和发展
协议网关BL110支持MODBUS多种协议转MQTT、OPC UA
关于合动力系统P2模块功能作用介绍
射频收发芯片GC0802用于无人机图像传输系统收发模块
世界人工智能大会首个“车载智能感知亿欧融合创新论坛”将正式举办
什么是焦耳加热？其实现方法是什么？
AMD的7nm锐龙3000将支持DDR4-5000内存
云平台远程控制继电器案例
从电视到照明 我国LED产业或迎井喷
首批参会企业名单亮相！GMIF2023全球存储器行业创新论坛与您相约深圳
瑞芯微全系列电子纸芯片方案，助力全行业数字化升级
新加坡电信推出数据中心新品牌Nxera
五分钟看完起亚K3S自动版 C-NCAP全部碰撞测试
小米9与荣耀V20对比究竟谁更值得购买
通信行业逐渐深化的变革正促使运营商向一点服务全国转变
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
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/pmem0on/mnttypexfs(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。
DTR8510变压器匝比测试仪的功能特点及应用范围
串口屏如何把同一个工程快速转换为不同分辨率工程
低功耗AI芯片加持摄像头 边缘设备智能化是安防新趋势
2019年Q1季度全球TOP10半导体芯片设计公司榜单公布 TOP5公司除了联发科其他全数衰退
“发现和合成量子点”斩获诺奖 晶能光电积极融入显示产业变革
Linux Kernel中AEP的现状和发展
协议网关BL110支持MODBUS多种协议转MQTT、OPC UA
关于合动力系统P2模块功能作用介绍
射频收发芯片GC0802用于无人机图像传输系统收发模块
世界人工智能大会首个“车载智能感知亿欧融合创新论坛”将正式举办
什么是焦耳加热？其实现方法是什么？
AMD的7nm锐龙3000将支持DDR4-5000内存
云平台远程控制继电器案例
从电视到照明 我国LED产业或迎井喷
首批参会企业名单亮相！GMIF2023全球存储器行业创新论坛与您相约深圳
瑞芯微全系列电子纸芯片方案，助力全行业数字化升级
新加坡电信推出数据中心新品牌Nxera
五分钟看完起亚K3S自动版 C-NCAP全部碰撞测试
小米9与荣耀V20对比究竟谁更值得购买
通信行业逐渐深化的变革正促使运营商向一点服务全国转变