
阅码场征稿Linux阅码场征集Linux工程师一线研发心得；工程师、高校学生老师、科研院所研研究人员对Linux某一技术要点深入分析的稿件。您的文章将获得近十万一线Linux工程师的广泛受众。投稿要求：原创且从未在任何媒体、博客、公众号发表过的文章。高屋建瓴、深刻全面地论述一个技术点或者面。投稿请微信联系小月：linuxer2016录取的稿件，我们也会奉上微薄的稿酬聊表寸心，稿费标准为300-500元/篇。

体系结构相关

5.10版本中RISC-V架构合入了UEFI这个大特性，这个特性由西数的两位工程师 Anup Patel和Atish Patra贡献，共7个补丁，支持了 early ioremap，用于UEFI启动内核所需的PE/COFF header，the RISC-V EFI stub和EFI runtime services。

此外， 5.10版本中有不少和ARM架构相关的特性，例如之前提到的MTE补丁，该功能借助ARMv8架构中不使用的几个高地址bit位（参见ARMv8 programming guide描述的TBI：Top Byte Ignore）作为tag，可以检测下面错误：bounds violations,，use-after-free, use-after-return, use-out-of-scope，use before initialization。用户空间MTE的支持和内核MTE的selftest测试用例该版本都合入了。内核空间MTE的支持则在5.11 merge window合入。

这个版本还增强了pointer authentication，Pointer authentication可以降低ROP(Return-oriented programming）攻击风险。和MTE类似，PAC使用了系统不使用的地址高位作为签名（PAC），5.10的版本中，增强了PAC的生成算法，并且当authenticate指令失败，会产生fault。值得注意的是，如果fault发给用户空间，这里的行为和之前的实现有变化，之前会给用户空间发SIGSEGV（Invalid memory reference），而目前会发送SIGILL(Illegal Instruction)。另外一个需要注意的是，MTE和pointer authentication都使用了地址都高位，如果同时打开，PAC可用比特会减少。

The arm64 architecture can now do performance-events monitoring over Arm’s CMN-600 interconnect

调测是系统软件很重要的一部分能力，有纯软件的方式，也有软硬结合的方式。例如想分析cache性能，可以通过硬件PMU（Performance Monitor Unit）得到cache miss rate等数据。PMU可以在CPU，总线等模块中。这个补丁提到的PMU是系统总线中的PMU。

CMN-600是ARM公司与2016年推出的系统总线IP，最大支持128个处理器和8T内存。CMN代表Coherent Mesh Network，顾名思义，是个网络结构，它的基本结构是XP（crosspoint）。CMN最大支持8x8=64个XP节点，每个节点可以支持两个Device，例如处理器，IO设备等，也包括调测设备，例如DTC。DTC是Debug Trace Controller的缩写，负责整体的PMU管理和中断（XP节点中有local monitor）。下图来自CMN-600 TRM，是一个3x5的mesh网络例子。

Linux系统的PMU是事件（event），通常的做法是通过perf_pmu_register注册。在arm cmn实现中，arm_cmn_probe调用了该函数注册pmu的attribute group和pmu的event，也就是注册该PMU支持的调测能力。例如arm cmn驱动中注册了400多种事件，其中PMU_HN_CACHE_MISS_EVENT和PMU_HNSLC_SF_CACHE_ACCESS_EVENT，可以用于计算cache miss rate（Cache miss rate (%) = Total cache misses/Total cache accessesx 100）。注册后，调用者（例如perf_event_open）初始化并注册event到perf_event_groups中，该event的相关处理函数是前述arm_cmn_probe注册的。这是Linux pmu event通常的管理方式。cmn驱动稍微多做了一些事情：cmn网络需要通过discovery发现，而不是固定写死的网络；发现之后，需要初始化前述的DTC，并为DTC注册中断。

这个补丁分为两部分，其中文档简述了CMN-600以及PMU驱动的一些实现考虑，具体实现在“ drivers/perf/arm-cmn.c“，感兴趣的童鞋可以根据前面内容读读代码（参见上图，图片节选自阅码场张健老师的ARM Linux课程）。

文件系统和Block Layer

ext4：两个提升性能的改进点

补丁1：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9faac62d40131521973192e46a82d5066bb42c09

补丁2：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5b8b297b04208e101c1f92fe804cd4e66df30e8

在ext4 的 iomap 中，如果是复写，在已经映射了块的情况下，直接使用已有的映射信息，而不是重新映射。一个非常简单的改动，在 DAX & DIO 模式下，能大幅提升文件随机复写的速度。在使能了模拟 pmem（DAX）的PPC64 VM设备上测试，约有10倍的随机复写性能提升。但在常规的 IO 操作（非 iomap）中，其实并不会有影响。

另外一个 fast commit 的新功能实用性更强。在 ext4 的 data=ordered 的日志模式中，会在日志中记录下完整的元数据。一个完整的元数据有时候也是有冗余的，大多时候改动可能只有一点点。能不能只记录涉及的最少改动？这就是 fast commit 新功能要做的事情。fast_commit 的功能需要在 mkfs 时使能，已有的旧的 ext4fs 并不能生效。

overlayfs：新增 volatile 的挂载参数

补丁：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c86243b090bc25f81abe33ddfa9fe833e02c4d64

我们通过 sync 来保证数据刷入，但如果太频繁的 sync 却会严重拖慢了性能。有使用者抱怨，dnf/yum 安装包时总会触发大量的 sync，严重拖慢了 image 的创建速度。

有些使用场景下，使用者并不希望频繁响应 sync，只需要在 umount 时回刷 overlayfs 的 upper layer 文件系统足够了。甚至根本不在意 upper layer 文件系统是否同步，如果数据不完整，丢弃并重新创建即可。

为了满足这样的需求，新支持了 volatile 挂载参数。在使能了这样的挂载参数后，对 upper layer 文件系统的任何形式的 sync 都会被忽略。

这个新的挂载参数并不常用，使用者应根据自己的场景来确定是否使能。

null_blk：一个测试不同块层实现的性能的模拟块设备

补丁：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dc4d137ee3b79a7474b747b4b326d472ccc2cb79

5.10 合入了一个关于 null_blk 的优化补丁，添加支持最大打开和活跃的 zones 的限制。相信大多数人也是第一次听说 null block 设备。/dev/null 的字符设备用多了，null block 是干嘛的呢？

null block 的资料非常少，只因其使用场景也非常局限。在 Linux 的文档中是少有的介绍 null block 设备的资料。null block 模拟了一个块设备，这个块设备不响应任何的读写操作，实际上，也仅仅是在 request 队列中直接标识 request 完成就返回了。可以发现，null block 虽然不对应任何具体的块设备，但经历过完整的块层，因此 null block 常用于测试不同块层实现模型的性能，例如 multi-queue 块层、single-queue块层、bio-based。

虚拟化和容器

在5.10 Release中我们在前几个月介绍过的几个补丁集已经被合并：

1. Add support for Nitro Enclaves。

Nitro Enclaves (NE)是Amazon弹性计算云(EC2)的一种新功能。它允许客户在EC2实例[1]内部再分割出一块隔离的计算环境。

例如，一个在虚拟机中运行的用于处理敏感数据的应用程序，可以和运行在同一个虚拟机中的其它应用程序分离开。我们称呼这个运行EC2实例的虚拟机为主虚拟机。分离后，这个应用程序运行在和主虚拟机不同的另外一个单独虚拟机里，也可以叫做enclave。

2. Support virtio cross-device resources。

这个补丁实现了VIRTIO跨设备的资源共享。他可以支持将VIRTIO资源导入到VIRTIO-VIDEO驱动中。

3. virtiofs: Adds DAX support。

该特性允许客户机在使用virtiofs文件系统时绕过客户机的页面缓存，同时允许客户机将主机上的页面缓存直接映射到客户机地址空间。这在很多数情况下，都可以大大提高访问速度。因为文件数据不必在客户机中复制，而是直接从主机页面缓存中访问，这可以节省大量内存。

还有一些补丁集我们之前没有介绍过，其中有一个关于vDPA的

vDPA: API for reporting IOVA range：

这个补丁集导出了一个API，可以向用户态程序报告IOVA范围。这是这个API的功能，可以让用户太进程根据返回的IOVA做出正确的决策:

1. 对于直接使用vhost-vDPA的用户太进程，IOVA必须在API返回的这个范围内分配。

2. 对于虚拟机(qemu)，当vIOMMU未启用时，如果GPA超出范围，则在前期就会失败

3. 对于虚拟机(qemu)，当vIOMMU被启用时，确定一个有效的虚拟机地址的范围大小后，虚拟机的IOVA分配器就可以正常工作了。

这个补丁比较简单，但我们正好借此机会简单介绍下vDPA （Virtual data path acceleration）：

vDPA本质上是一种标准化的方法用来设计SRIOV的网卡。让SRIOV网卡在数据面使用VIRTIO Ring的设计布局，这样在虚拟机中就只需要单一的VIRTIO网卡驱动，而不需要部属各种厂商SRIOV网卡VF的驱动。这样相当于将虚拟机和具体的网卡硬件厂商解耦。这不仅仅便于虚拟机的迁移，也方便于虚拟机镜像的安全认证，不再需要因为更换了网卡的硬件添加了新的VF驱动再去认证虚拟机镜像。除了数据面之外，它还定义了一个通用的控制面和软件的底层基础架构来支持它。因此vDPA也可以被看作是SRIOV的一个上层抽象。

那么有的朋友可能会问，这个和VIRTIO full offload到硬件的方案有什么区别？这个从虚拟机里面的最终使用者来看，其实没有太大的区别，在虚拟机内部都是使用一个VIRTIO网卡驱动。vDPA带来的是降低VIRTIO硬件网卡的设计难度，然后提供更好的设计灵活性。我们都知道一个VIRTIO设备包括数据面（通过vring中存储数据）和控制面（vring的初始化等）。我们在上面的vDPA中提到了控制面，但那个并不是VIRTIO控制面。VIRTIO full offload方案中需要硬件厂商在网卡硬件层面实现VIRTIO的数据面和控制面，数据面的难度比较低，但是控制面会复杂很多，因为这个涉及和内存管理单元（IOMMU）的交互。而且VIRTIO full offload也会带来产品的同质化，不利于厂商做差异化功能，这样才有了vDPA。

vDPA的控制面可以简单看作是一个转换层。虚拟机通过vDPA看到的仍然是VIRTIO的控制面接口，不是各个厂商定义的控制面接口。但是vDPA的控制面可以将虚拟机的VIRTIO控制命令，通过vDPA定义的通用控制面接口转换为各个厂商自定义的接口。这只需要在主机端添加vDPA设备厂商提供的vDPA addon驱动即可。厂商的vDPA-addon驱动可以包含它自己的接口和DMA访问模型支持等复杂功能。

简而言之，vDPA是一种比VIRTIO full offload更加灵活的设计方法，让网卡设计厂商可以用更小的代价支持VIRTIO硬件Ring，并仍然在数据平面上实现线速性能。

因此当我们讨论一个“vDPA设备”时，就意味着这个设备的数据面是符合VIRTIO标准的，但它的控制面是厂商自己定义的。

（END）


更多精彩，尽在"Linux阅码场"，扫描下方二维码关注

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/秋刀鱼在做梦/article/detail/944892

Linux阅码场 - Linux内核月报(2020年12月)

体系结构相关

文件系统和Block Layer

虚拟化和容器