为什么mmap之后访问地址仍然发生了缺页异常？

发表于 2年以前 | 总阅读数：584 次

问题简述

在笔者的开发平台上，应用程序使用ION申请cma内存，并用mmap映射到用户地址空间去做写操作。

重点代码摘要如下：

客户希望提高

node->var = some_value;

这里的访问效率（实际代码要复杂些，是申请了一个大数组并往里循环读写数据）。

第一轮分析

首先用perf分析应用程序行为，发现程序在运行时产生了不少page fault，感觉是mmap之后内核并没有建立映射，而是在第一次访问此地址时，产生fault in所致。

第一个想法

首先想到优化点是：用MAP_POPULATE强制在mmap系统调用里面把所有的页面都fault in，这样后面访问就不会产生page fault而耽误时间了。因为page fault不管是在前还是在后总会发生，这个优化思路其实只是让这段时间集中挪到了访问数据之前。但看了一下mmap的手册，说到MAP_POPULATE只能针对于MAP_PRIVATE映射（见mmap手册），比如用匿名页建立的映射，而此处因为是MAP_SHARED，无法用MAP_POPULATE,故此方案作罢。

第二个想法

用ftrace跟踪了一下ion代码，发现mmap已经调用了remap_pfn_range来建立页面映射，代码路径如下：

mmap => el0_sync => el0_sync_handler => el0_svc => do_el0_svc => el0_svc_common.constprop.4 => __arm64_sys_mmap => ksys_mmap_pgoff => vm_mmap_pgoff => do_mmap => mmap_region => dma_buf_mmap_internal => ion_dma_buf_mmap => ion_heap_map_user => remap_pfn_range

也就是说，从代码路径看，在mmap系统调用中，用户页已经全都建立好了，所谓的fault in其实并不存在。那么问题来了，既然不存在fault in,为什么还是会产生page fault呢？

转机

因为此问题是在换了内核到5.10之后暴露出来的，尝试在旧内核4.19上尝试同样的代码。

同样代码运行在4.19内核上，该写操作的效率明显高于5.10内核。对比由perf stat观测得出：

也就是说，4.19上面代码如预期运行，mmap时后就不再有page fault，但5.10上却发生了page fault。

问题就转变成了：为什么remap_pfn_range之后仍发生了page fault？

分析remap_pfn_range行为发现应该不是这里的问题，那么，或许这个page fault不是缺页异常，而是别的page fault？想到这一层后，继续对比4.19与5.10内核行为。

问题原因的要素分析

跳过冗长的debug过程，直接说5.10内核在笔者平台上造成此问题的根本原因，原因由这几个要素构成：

1 . mmap在使用ION的时候，需要用参数MAP_SHARED

此参数最终会传导至ARM64 arch层在设置相应页表时，采用PAGE_SHARED联合属性
PAGE_SHARED联合属性，包含这样两个页表基本属性：PTE_RDONLY | PTE_DBM

2 . 根据ARMv8手册，PTE_RDONLY | PTE_DBM 两个属性叠加，根据另一个系统寄存器的不同配置，会有两种不同硬件处理的情况：二选一

系统寄存器TCR_EL1.HD=1产生的效果是：在第一次写操作访问该页面时，CPU会自动更新页面的RO属性为RW，并不产生permission fault
系统寄存器TCR_EL1.HD=0产生的效果是：在第一次写操作访问该页面时，CPU不会自动更新页面的RO属性为RW，而会产生一次permission fault，这个fault需要由操作系统去软件更新为RW，它的主要目的，是为了让操作系统跟踪页表第一次写访问。

3 . 在笔者的内核编译中，系统寄存器TCR_EL1.HD=0，也就是走的B路线。

之所以编译会让该位配置为0，是因为需要实施一个CPU erratum的软件规避：Cortex-A55: 1024718: Update of DBM/AP bits without break before make might result in incorrect update，表现为内核配置项CONFIG_ARM64_ERRATUM_1024718
CPU erratum是那些ARM core IP在设计时的缺陷所致的CPU硬件bug，因为IP已经集成在市面上的SoC里流片，不可能重新设计，只能通过软件做一些规避，这些规避方法，均记录在ARM的官方Errata文档（CPU勘误手册）里。
以A55来说，此Erratum编号为1024718，影响范围是所有版本号<=r2p0的Cortex-A55 core IP，规避办法是设置TCR_EL1.HD=0
笔者平台的CPU版本号，正好是r2p0，恰好在此Erratum的范围内，必须实施CONFIG_ARM64_ERRATUM_1024718

综上，5.10内核，因为上述的全部要素联合，就产生了这个permission page fault。

问题解决方案

目前采用的办法是一个workaround（而非fix）：单把PAGE_SHARED属性回退为与4.19内核一致（参考前文提到的那个commit）。实测性能与4.19几乎无差别了：

因为那个ARM官方的commit是社区深思熟虑的刻意行为，回退并不现实，根本解决办法，应该是给出一个综合的patch，使得方方面面的情况都照顾到。

问题回顾

这个bug卡笔者最长的时间，其实是在这一条：为什么remap_pfn_range之后仍发生了page fault？因为笔者先入为主的观念，把所有page fault都当成了缺页异常，而没有第一时间想到permission fault的可能，导致浪费了大量时间来分析remap_pfn_range的行为，虽然代码逻辑整理了不少，但一直没能进入核心要点。这一点突破以后，后面的分析和解决就是水到渠成的事情了。