442
体系结构相关
5.10版本中RISC-V架构合入了UEFI这个大特性，这个特性由西数的两位工程师AnupPatel和AtishPatra贡献，共7个补丁，支持了earlyioremap，用于UEFI启动内核所需的PE/COFFheader，theRISC-VEFIstub和EFIruntimeservices。
此外，5.10版本中有不少和ARM架构相关的特性，例如之前提到的MTE补丁，该功能借助ARMv8架构中不使用的几个高地址bit位（参见ARMv8programmingguide描述的TBI：TopByteIgnore）作为tag，可以检测下面错误：boundsviolations,，use-after-free,use-after-return,use-out-of-scope，usebeforeinitialization。用户空间MTE的支持和内核MTE的selftest测试用例该版本都合入了。内核空间MTE的支持则在5.11mergewindow合入。
这个版本还增强了pointerauthentication，Pointerauthentication可以降低ROP(Return-orientedprogramming）攻击风险。和MTE类似，PAC使用了系统不使用的地址高位作为签名（PAC），5.10的版本中，增强了PAC的生成算法，并且当authenticate指令失败，会产生fault。值得注意的是，如果fault发给用户空间，这里的行为和之前的实现有变化，之前会给用户空间发SIGSEGV（Invalidmemoryreference），而目前会发送SIGILL(IllegalInstruction)。另外一个需要注意的是，MTE和pointerauthentication都使用了地址都高位，如果同时打开，PAC可用比特会减少。
Thearm64architecturecannowdoperformance-eventsmonitoringoverArm’sCMN-600interconnect
调测是系统软件很重要的一部分能力，有纯软件的方式，也有软硬结合的方式。例如想分析cache性能，可以通过硬件PMU（PerformanceMonitorUnit）得到cachemissrate等数据。PMU可以在CPU，总线等模块中。这个补丁提到的PMU是系统总线中的PMU。
CMN-600是ARM公司与2016年推出的系统总线IP，最大支持128个处理器和8T内存。CMN代表CoherentMeshNetwork，顾名思义，是个网络结构，它的基本结构是XP（crosspoint）。CMN最大支持8x8=64个XP节点，每个节点可以支持两个Device，例如处理器，IO设备等，也包括调测设备，例如DTC。DTC是DebugTraceController的缩写，负责整体的PMU管理和中断（XP节点中有localmonitor）。下图来自CMN-600TRM，是一个3x5的mesh网络例子。
Linux系统的PMU是事件（event），通常的做法是通过perf_pmu_register注册。在armcmn实现中，arm_cmn_probe调用了该函数注册pmu的attributegroup和pmu的event，也就是注册该PMU支持的调测能力。例如armcmn驱动中注册了400多种事件，其中PMU_HN_CACHE_MISS_EVENT和PMU_HNSLC_SF_CACHE_ACCESS_EVENT，可以用于计算cachemissrate（Cachemissrate(%)=Totalcachemisses/Totalcacheaccessesx100）。注册后，调用者（例如perf_event_open）初始化并注册event到perf_event_groups中，该event的相关处理函数是前述arm_cmn_probe注册的。这是Linuxpmuevent通常的管理方式。cmn驱动稍微多做了一些事情：cmn网络需要通过discovery发现，而不是固定写死的网络；发现之后，需要初始化前述的DTC，并为DTC注册中断。
这个补丁分为两部分，其中文档简述了CMN-600以及PMU驱动的一些实现考虑，具体实现在“drivers/perf/arm-cmn.c“，感兴趣的童鞋可以根据前面内容读读代码（参见上图，图片节选自阅码场张健老师的ARMLinux课程）。
文件系统和BlockLayer
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）的PPC64VM设备上测试，约有10倍的随机复写性能提升。但在常规的IO操作（非iomap）中，其实并不会有影响。
另外一个fastcommit的新功能实用性更强。在ext4的data=ordered的日志模式中，会在日志中记录下完整的元数据。一个完整的元数据有时候也是有冗余的，大多时候改动可能只有一点点。能不能只记录涉及的最少改动？这就是fastcommit新功能要做的事情。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的upperlayer文件系统足够了。甚至根本不在意upperlayer文件系统是否同步，如果数据不完整，丢弃并重新创建即可。
为了满足这样的需求，新支持了volatile挂载参数。在使能了这样的挂载参数后，对upperlayer文件系统的任何形式的sync都会被忽略。
这个新的挂载参数并不常用，使用者应根据自己的场景来确定是否使能。
null_blk：一个测试不同块层实现的性能的模拟块设备
补丁：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dc4d137ee3b79a7474b747b4b326d472ccc2cb79
5.10合入了一个关于null_blk的优化补丁，添加支持最大打开和活跃的zones的限制。相信大多数人也是第一次听说nullblock设备。/dev/null的字符设备用多了，nullblock是干嘛的呢？
nullblock的资料非常少，只因其使用场景也非常局限。在Linux的文档中是少有的介绍nullblock设备的资料。nullblock模拟了一个块设备，这个块设备不响应任何的读写操作，实际上，也仅仅是在request队列中直接标识request完成就返回了。可以发现，nullblock虽然不对应任何具体的块设备，但经历过完整的块层，因此nullblock常用于测试不同块层实现模型的性能，例如multi-queue块层、single-queue块层、bio-based。
虚拟化和容器
在5.10Release中我们在前几个月介绍过的几个补丁集已经被合并：
1. AddsupportforNitroEnclaves。
NitroEnclaves(NE)是Amazon弹性计算云(EC2)的一种新功能。它允许客户在EC2实例[1]内部再分割出一块隔离的计算环境。
例如，一个在虚拟机中运行的用于处理敏感数据的应用程序，可以和运行在同一个虚拟机中的其它应用程序分离开。我们称呼这个运行EC2实例的虚拟机为主虚拟机。分离后，这个应用程序运行在和主虚拟机不同的另外一个单独虚拟机里，也可以叫做enclave。
2. Supportvirtiocross-deviceresources。
这个补丁实现了VIRTIO跨设备的资源共享。他可以支持将VIRTIO资源导入到VIRTIO-VIDEO驱动中。
3. virtiofs:AddsDAXsupport。
该特性允许客户机在使用virtiofs文件系统时绕过客户机的页面缓存，同时允许客户机将主机上的页面缓存直接映射到客户机地址空间。这在很多数情况下，都可以大大提高访问速度。因为文件数据不必在客户机中复制，而是直接从主机页面缓存中访问，这可以节省大量内存。
还有一些补丁集我们之前没有介绍过，其中有一个关于vDPA的
vDPA:APIforreportingIOVArange：
这个补丁集导出了一个API，可以向用户态程序报告IOVA范围。这是这个API的功能，可以让用户太进程根据返回的IOVA做出正确的决策:
1. 对于直接使用vhost-vDPA的用户太进程，IOVA必须在API返回的这个范围内分配。
2. 对于虚拟机(qemu)，当vIOMMU未启用时，如果GPA超出范围，则在前期就会失败。
3. 对于虚拟机(qemu)，当vIOMMU被启用时，确定一个有效的虚拟机地址的范围大小
后，虚拟机的IOVA分配器就可以正常工作了。
这个补丁比较简单，但我们正好借此机会简单介绍下
vDPA（Virtualdatapathacceleration）：
vDPA本质上是一种标准化的方法用来设计SRIOV的网卡。让SRIOV网卡在数据面使用VIRTIORing的设计布局，这样在虚拟机中就只需要单一的VIRTIO网卡驱动，而不需要部属各种厂商SRIOV网卡VF的驱动。这样相当于将虚拟机和具体的网卡硬件厂商解耦。这不仅仅便于虚拟机的迁移，也方便于虚拟机镜像的安全认证，不再需要因为更换了网卡的硬件添加了新的VF驱动再去认证虚拟机镜像。除了数据面之外，它还定义了一个通用的控制面和软件的底层基础架构来支持它。因此vDPA也可以被看作是SRIOV的一个上层抽象。
那么有的朋友可能会问，这个和VIRTIOfulloffload到硬件的方案有什么区别？这个从虚拟机里面的最终使用者来看，其实没有太大的区别，在虚拟机内部都是使用一个VIRTIO网卡驱动。vDPA带来的是降低VIRTIO硬件网卡的设计难度，然后提供更好的设计灵活性。我们都知道一个VIRTIO设备包括数据面（通过vring中存储数据）和控制面（vring的初始化等）。我们在上面的vDPA中提到了控制面，但那个并不是VIRTIO控制面。
VIRTIOfulloffload方案中需要硬件厂商在网卡硬件层面实现VIRTIO的数据面和控制面，数据面的难度比较低，但是控制面会复杂很多，因为这个涉及和内存管理单元（IOMMU）的交互。而且VIRTIOfulloffload也会带来产品的同质化，不利于厂商做差异化功能，这样才有了vDPA。
vDPA的控制面可以简单看作是一个转换层。虚拟机通过vDPA看到的仍然是VIRTIO的控制面接口，不是各个厂商定义的控制面接口。但是vDPA的控制面可以将虚拟机的VIRTIO控制命令，通过vDPA定义的通用控制面接口转换为各个厂商自定义的接口。这只需要在主机端添加vDPA设备厂商提供的vDPAaddon驱动即可。厂商的vDPA-addon驱动可以包含它自己的接口和DMA访问模型支持等复杂功能。
简而言之，vDPA是一种比VIRTIOfulloffload更加灵活的设计方法，让网卡设计厂商可以用更小的代价支持VIRTIO硬件Ring，并仍然在数据平面上实现线速性能。
因此当我们讨论一个“vDPA设备”时，就意味着这个设备的数据面是符合VIRTIO标准的，但它的控制面是厂商自己定义的。
