Linux内存–管理和碎片
本系列有如下几篇
物理结构分析
内存从物理结构上面分为：Channel > DIMM（对应物理上售卖的内存条） >Rank > Chip > Bank > Row/Column。
Chip就是DRAM芯片，一个chip里面会有很多bank。每个bank就是数据存储的实体，相当于一个二维矩阵，只要声明了column和row就可以从每个bank中取出8bit的数据。
具体可以看如下图，一个通道Channel可以是一个DIMM也可以是两个DIMM，甚至3个DIMM，图中是2个DIMM。
虚拟内存和物理内存
进程所操作的内存是一个虚拟内存，由OS来将这块虚拟内存映射到实际的物理内存上，这样做的好处是每个进程可以独占 128T 内存，任意地使用，系统上还运行了哪些进程已经与我们完全没有关系了（不需要考虑和其它进程之间的地址会冲突）。为变量和函数分配地址的活，我们交给链接器去自动安排就可以了。这一切都是因为虚拟内存能够提供内存地址空间的隔离，极大地扩展了可用空间。
操作系统管理着这种映射关系，所以你在写代码的时候，就不用再操心物理内存的使用情况了，你看到的内存就是虚拟内存。无论一个进程占用的内存资源有多大，在任一时刻，它需要的物理内存都是很少的。在这个推论的基础上，CPU 为每个进程只需要保留很少的物理内存就可以保证进程的正常执行了。
当程序中使用 malloc 等分配内存的接口时会将内存从待分配状态变成已分配状态，此时这块分配好的内存还没有真正映射到对应的物理内存上，这块内存就是未映射状态，因为它并没有被映射到相应的物理内存，直到对该块内存进行读写时，操作系统才会真正地为它分配物理内存。然后这个页面才能成为正常页面。
i7 处理器的页表也是存储在内存页里的，每个页表项都是 4 字节。所以，人们就将 1024 个页表项组成一张页表。这样一张页表的大小就刚好是 4K，占据一个内存页，这样就更加方便管理。而且，当前市场上主流的处理器也都选择将页大小定为 4K。
虚拟地址在计算机体系结构里可以评为特优的一项技术；超线程、流水线、多发射只是优；cache则只是良好（成本高）
CPU 如何找到真实地址
- 第一步是确定页目录基址。每个 CPU 都有一个页目录基址寄存器，最高级页表的基地址就存在这个寄存器里。在 X86 上，这个寄存器是 CR3。每一次计算物理地址时，MMU 都会从 CR3 寄存器中取出页目录所在的物理地址。
- 第二步是定位页目录项（PDE）。一个 32 位的虚拟地址可以拆成 10 位，10 位和 12 位三段，上一步找到的页目录表基址加上高 10 位的值乘以 4，就是页目录项的位置。这是因为，一个页目录项正好是 4 字节，所以 1024 个页目录项共占据 4096 字节，刚好组成一页，而 1024 个页目录项需要 10 位进行编码。这样，我们就可以通过最高 10 位找到该地址所对应的 PDE 了。
- 第三步是定位页表项（PTE）。页目录项里记录着页表的位置，CPU 通过页目录项找到页表的位置以后，再用中间 10 位计算页表中的偏移，可以找到该虚拟地址所对应的页表项了。页表项也是 4 字节的，所以一页之内刚好也是 1024 项，用 10 位进行编码。所以计算公式与上一步相似，用页表基址加上中间 10 位乘以 4，可以得到页表项的地址。
- 最后一步是确定真实的物理地址。上一步 CPU 已经找到页表项了，这里存储着物理地址，这才真正找到该虚拟地址所对应的物理页。虚拟地址的低 12 位，刚好可以对一页内的所有字节进行编码，所以我们用低 12 位来代表页内偏移。计算的公式是物理页的地址直接加上低 12 位。
前面我们分析的是 32 位操作系统，那对于 64 位机器是不是有点不同呢？在 64 位的机器上，使用了 48 位的虚拟地址，所以它需要使用 4 级页表。它的结构与 32 位的 3 级页表是相似的，只是多了一级页目录，定位的过程也从 32 位的 4 步变成了 5 步。
8086最开始是按不同的作用将内存分为代码段、数据段等，386开始按页开始管理内存（混合有按段管理）。 现代的操作系统都是采用段式管理来做基本的权限管理，而对于内存的分配、回收、调度都是依赖页式管理。
tlab miss
tlb：从各级cache里分配的一块专用空间，用来存放页表(虚拟地址和物理地址的对应关系)
|
|
TLB(Translation Lookaside Buffer) Cache用于缓存少量热点内存地址的mapping关系。TLB和L1一样每个core独享，由于制造成本和工艺的限制，响应时间需要控制在CPU Cycle级别的Cache容量只能存储几十个对象。那么TLB Cache在应对大量热点数据Virual Address转换的时候就显得捉襟见肘了。我们来算下按照标准的Linux页大小(page size) 4K，一个能缓存64元素的TLB Cache只能涵盖4K*64 = 256K的热点数据的内存地址，显然离理想非常遥远的。于是Huge Page就产生了。
These are typical performance levels of a TLB:
- Size: 12 bits – 4,096 entries
- Hit time: 0.5 – 1 clock cycle
- Miss penalty: 10 – 100 clock cycles
- Miss rate: 0.01 – 1% (20–40% for sparse/graph applications)
TLB也分为iTLB和dTLB, 分别顶在L1i和L1d前面（比L1更小更快，每个core独享tlb）
以intel x86为例，一个cpu也就32到64个tlb, 超出这个范畴，就得去查页表。 每个型号的cpu都不一样，需要查看spec
进程分配到的不是内存的实际物理地址，而是一个经过映射后的虚拟地址，这么做的原因是为了让每个应用可以独享完整的虚拟地址，而不需要每个进程互相考虑使用内存的协调。
但是虚拟地址到物理地址的映射需要巨大的映射空间，如何用更少的内存消耗来管理庞大的内存（如果没有分级，4G内存对应着4MB的索引空间，一级比如使用4K就够了，多个二级使总共用4M，但是这4M大部分时候不用提前分配），Linux通过四级表项来做虚拟地址到物理地址的映射，这样4Kb就能管理256T内存，4级映射是时间换空间的典型案例。不过一般而言一个进程是远远用不了256T内存的，那么这四级映射大部分时候都是没必要的，所以实际用不了那么大的PageTable。
虚拟内存的核心原理是：为每个程序设置一段”连续”的虚拟地址空间，把这个地址空间分割成多个具有连续地址范围的页 (page)，并把这些页和物理内存做映射，在程序运行期间动态映射到物理内存。当程序引用到一段在物理内存的地址空间时，由硬件立刻执行必要的映射；而当程序引用到一段不在物理内存中的地址空间时，由操作系统负责将缺失的部分装入物理内存并重新执行失败的指令：
在 内存管理单元（Memory Management Unit，MMU）进行地址转换时，如果页表项的 “在/不在” 位是 0，则表示该页面并没有映射到真实的物理页框，则会引发一个缺页中断，CPU 陷入操作系统内核，接着操作系统就会通过页面置换算法选择一个页面将其换出 (swap)，以便为即将调入的新页面腾出位置，如果要换出的页面的页表项里的修改位已经被设置过，也就是被更新过，则这是一个脏页 (dirty page)，需要写回磁盘更新改页面在磁盘上的副本，如果该页面是”干净”的，也就是没有被修改过，则直接用调入的新页面覆盖掉被换出的旧页面即可。
还需要了解的一个概念是转换检测缓冲器（Translation Lookaside Buffer，TLB，每个core一个TLB，类似L1 cache），也叫快表，是用来加速虚拟地址映射的，因为虚拟内存的分页机制，页表一般是保存内存中的一块固定的存储区，导致进程通过 MMU 访问内存比直接访问内存多了一次内存访问，性能至少下降一半，因此需要引入加速机制，即 TLB 快表，TLB 可以简单地理解成页表的高速缓存，保存了最高频被访问的页表项，由于一般是硬件实现的，因此速度极快，MMU 收到虚拟地址时一般会先通过硬件 TLB 查询对应的页表号，若命中且该页表项的访问操作合法，则直接从 TLB 取出对应的物理页框号返回，若不命中则穿透到内存页表里查询，并且会用这个从内存页表里查询到最新页表项替换到现有 TLB 里的其中一个，以备下次缓存命中。
如果没有TLB那么每一次内存映射都需要查表四次然后才是一次真正的内存访问，代价比较高。
有了TLB之后，CPU访问某个虚拟内存地址的过程如下
- CPU产生一个虚拟地址
- MMU从TLB中获取页表，翻译成物理地址
- MMU把物理地址发送给L1/L2/L3/内存
- L1/L2/L3/内存将地址对应数据返回给CPU
由于第2步是类似于寄存器的访问速度，所以如果TLB能命中，则虚拟地址到物理地址的时间开销几乎可以忽略。tlab miss比较高的话开启内存大页对性能是有提升的，但是会有一定的内存浪费。
内存布局
- 代码段：CPU 运行一个程序，实质就是在顺序执行该程序的机器码。一个程序的机器码会被组织到同一个地方。
- 数据段：程序在运行过程中必然要操作数据。这其中，对于有初值的变量，它的初始值会存放在程序的二进制文件中，而且，这些数据部分也会被装载到内存中，即程序的数据段。数据段存放的是程序中已经初始化且不为 0 的全局变量和静态变量。
- BSS 段: 对于未初始化的全局变量和静态变量，因为编译器知道它们的初始值都是 0，因此便不需要再在程序的二进制映像中存放这么多 0 了，只需要记录他们的大小即可，这便是BSS段 。BSS 段这个缩写名字是 Block Started by Symbol，但很多人可能更喜欢把它记作 Better Save Space 的缩写。
- 堆是程序员可以自由申请的空间，当我们在写程序时要保存数据，优先会选择堆；
- 栈是函数执行时的活跃记录，这将是我们下一节课要重点分析的内容。
数据段和 BSS 段里存放的数据也只能是部分数据，主要是全局变量和静态变量，但程序在运行过程中，仍然需要记录大量的临时变量，以及运行时生成的变量，这里就需要新的内存区域了，即程序的堆空间跟栈空间。与代码段以及数据段不同的是，堆和栈并不是从磁盘中加载，它们都是由程序在运行的过程中申请，在程序运行结束后释放。
总的来说，一个程序想要运行起来所需要的几块基本内存区域：代码段、数据段、BSS 段、堆空间和栈空间。下面就是内存布局的示意图：
其它内存形态：
- 存放加载的共享库的内存空间：如果一个进程依赖共享库，那对应的，该共享库的代码段、数据段、BSS 段也需要被加载到这个进程的地址空间中。
- 共享内存段：我们可以通过系统调用映射一块匿名区域作为共享内存，用来进行进程间通信。
- 内存映射文件：我们也可以将磁盘的文件映射到内存中，用来进行文件编辑或者是类似共享内存的方式进行进程通信。
32位 x86机器下，通过 cat /proc/pid/maps 看到的进程所使用的内存分配空间：
64位 x86机器下，通过 cat /proc/pid/maps 看到的进程所使用的内存分配空间：
目前的 64 系统下的寻址空间是 2^48(太多用不完，高16位为Canonical空间），即 256TB。而且根据 canonical address 的划分，地址空间天然地被分割成两个区间，分别是 0x0 - 0x00007fffffffffff 和 0xffff800000000000 - 0xffffffffffffffff。这样就直接将低 128T 的空间划分为用户空间，高 128T 划分为内核空间。
brk:内核维护指向堆的顶部
Java程序对应的maps：
|
|
内存管理和使用
malloc
malloc()分配内存时：
- 如果用户分配的内存小于 128 KB，则通过 brk() 申请内存–在堆顶分配；
- 如果用户分配的内存大于 128 KB，则通过 mmap() 申请内存–从文件映射区域分配；
对于 「malloc 申请的内存，free 释放内存会归还给操作系统吗？」：
- malloc 通过 brk() 方式申请的内存，free 释放内存的时候，并不会把内存归还给操作系统，而是缓存在 malloc 的内存池中，待下次使用–小内存分配避免反复调用系统操作导致上下文切换，缺点是没回收容易导致内存碎片进而浪费内存。brk分配出来的内存在maps中显示有heap字样；
- malloc 通过 mmap() 方式申请的内存，free 释放内存的时候，会把内存归还给操作系统，内存得到真正的释放。并且mmap分配的虚拟内存都是缺页状态的。
malloc和mmap
glibc中的malloc/free 负责向内核批发内存（不需要每次分配都真正地去调用内核态来分配），分配好的内存按大小分成不同的桶，每次malloc的时候实际到对应的桶上摘取对应的块(slab)就好，用完free的时候挂回去。
mmap映射内存
私有匿名映射常用于分配内存，也就是申请堆内存
分桶式内存管理比简单算法无论是在算法效率方面，还是在碎片控制方面都有很大的提升。但它的缺陷也很明显：区域内部的使用率不够高和动态扩展能力不够好。例如，4 字节的区域提前消耗完了，但 8 字节的空闲区域还有很多，此时就会面临两难选择，如果直接分配 8 字节的区域，则区域内部浪费就比较多，如果不分配，则明明还有空闲区域，却无法成功分配。
为了解决以上问题所以搞了buddy
node->zone->buddy->slab
假如需要分配一块 4 字节大小的空间，但是在 4 字节的 free list 上找不到空闲区域，系统就会往上找，假如 8 字节和 16 字节的 free list 中也没有空闲区域，就会一直向上找到 32 字节的 free list。
伙伴系统不会直接把 32 的空闲区域分配出去，因为这样做的话，会带来巨大的浪费。它会先把 32 字节分成两个 16 字节，把后边一个挂入到 16 字节的 free list 中。然后继续拆分前一半。前一半继续拆成两个 8 字节，再把后一半挂入到 8 字节的 free list，最后，把前一半 8 字节拿去分配，当然这里也要继续拆分成两个 4 字节的空闲区域，其中一个用于本次 malloc 分配，另一个则挂入到 4 字节的 free list。分配后的内存的状态如下所示：
查看zone
DMAis the low 16 MBytes of memory. At this point it exists for historical reasons; once upon what is now a long time ago, there was hardware that could only do DMA into this area of physical memory.DMA32exists only in 64-bit Linux; it is the low 4 GBytes of memory, more or less. It exists because the transition to large memory 64-bit machines has created a class of hardware that can only do DMA to the low 4 GBytes of memory.(This is where people mutter about everything old being new again.)Normalis different on 32-bit and 64-bit machines. On 64-bit machines, it is all RAM from 4GB or so on upwards. On 32-bit machines it is all RAM from 16 MB to 896 MB for complex and somewhat historical reasons. Note that this implies that machines with a 64-bit kernel can have very small amounts of Normal memory unless they have significantly more than 4GB of RAM. For example, a 2 GB machine running a 64-bit kernel will have no Normal memory at all while a 4 GB machine will have only a tiny amount of it.HighMemexists only on 32-bit Linux; it is all RAM above 896 MB, including RAM above 4 GB on sufficiently large machines.
每个zone下很多pages(大小为4K)，buddy就是这些Pages的组织管理者
|
|
每个页面大小是4K，很容易可以计算出每个 zone 的大小。比如对于上面 Node0 的 Normal， 197571780 4K/(10241024) = 753 GB。
dmidecode 可以查看到服务器上插着的所有内存条，也可以看到它是和哪个CPU直接连接的。每一个CPU以及和他直连的内存条组成了一个 node（节点）
/proc/buddyinfo
/proc/buddyinfo记录了可用内存的情况。
Normal那行之后的第二列表示： 643847*2^1*Page_Size(4K) ; 第三列表示： 357451*2^2*Page_Size(4K) ，高阶内存指的是2^3及更大的内存块。
应用申请大块连续内存（高阶内存，一般之4阶及以上, 也就是64K以上–2^4*4K）时，容易导致卡顿。这是因为大块连续内存确实系统需要触发回收或者碎片整理，需要一定的时间。
|
|
/proc/pagetypeinfo
cat /proc/pagetypeinfo, 你可以看到当前系统里伙伴系统里各个尺寸的可用连续内存块数量。unmovable pages是不可以被迁移的，比如slab等kmem都不可以被迁移，因为内核里面对这些内存很多情况下是通过指针来访问的，而不是通过页表，如果迁移的话，就会导致原来的指针访问出错。
当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重
alloc_pages分配内存的时候就到上面对应大小的free_area的链表上寻找可用连续页面。alloc_pages是怎么工作的呢？我们举个简单的小例子。假如要申请8K-连续两个页框的内存。为了描述方便，我们先暂时忽略UNMOVEABLE、RELCLAIMABLE等不同类型
基于伙伴系统的内存分配中，有可能需要将大块内存拆分成两个小伙伴。在释放中，可能会将两个小伙伴合并再次组成更大块的连续内存。
伙伴系统中的伙伴指的是两个内存块，大小相同，地址连续，同属于一个大块区域。
对于应用来说基本分配单位是4K(开启大页后一般是2M)，对于内核来说4K有点浪费。所以内核又专门给自己定制了一个更精细的内存管理系统slab。
slab
对于内核运行中实际使用的对象来说，多大的对象都有。有的对象有1K多，但有的对象只有几百、甚至几十个字节。如果都直接分配一个 4K的页面 来存储的话也太浪费了，所以伙伴系统并不能直接使用。
在伙伴系统之上，内核又给自己搞了一个专用的内存分配器， 叫slab。
这个分配器最大的特点就是，一个slab内只分配特定大小、甚至是特定的对象。这样当一个对象释放内存后，另一个同类对象可以直接使用这块内存。通过这种办法极大地降低了碎片发生的几率。
kmem cache
slabtop和/proc/slabinfo 查看cached使用情况 主要是：pagecache（页面缓存）， dentries（目录缓存）， inodes
通过查看 /proc/slabinfo 我们可以查看到所有的 kmem cache。
slabtop 按占用内存从大往小进行排列。用来分析 slab 内存开销。
无论是 /proc/slabinfo，还是 slabtop 命令的输出。里面都包含了每个 cache 中 slab的如下几个关键属性。
- objsize：每个对象的大小
objperslab：一个 slab 里存放的对象的数量
pagesperslab：一个slab 占用的页面的数量，每个页面4K，这样也就能算出每个 slab 占用的内存大小。
比如如下TCP slabinfo中可以看到每个slab占用8(pagesperslab)个Page(84096=32768)，每个对象的大小是1984(objsize)，每个slab存放了16(objperslab)个对象. 那么1984 16=31744，现在的空间基本用完，剩下接近1K，又放不下一个1984大小的对象，算是额外开销了。
|
|
内存分配和延迟
内存不够、脏页太多、碎片太多，都会导致分配失败，从而触发回收，导致卡顿。
系统中脏页过多引起 load 飙高
直接回收过程中，如果存在较多脏页就可能涉及在回收过程中进行回写，这可能会造成非常大的延迟，而且因为这个过程本身是阻塞式的，所以又可能进一步导致系统中处于 D 状态的进程数增多，最终的表现就是系统的 load 值很高。
可以通过 sar -r 来观察系统中的脏页个数：
|
|
kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
至于这些值调整大多少比较合适，也是因系统和业务的不同而异，我的建议也是一边调整一边观察，将这些值调整到业务可以容忍的程度就可以了，即在调整后需要观察业务的服务质量 (SLA)，要确保 SLA 在可接受范围内。调整的效果你可以通过 /proc/vmstat 来查看：
|
|
在4.20的内核并且sar 的版本为12.3.3可以看到PSI（Pressure-Stall Information）
|
|
你需要重点关注 avg10 这一列，它表示最近 10s 内存的平均压力情况，如果它很大（比如大于 40）那 load 飙高大概率是由于内存压力，尤其是 Page Cache 的压力引起的。
容器中的内存回收
kswapd线程(每个node一个kswapd进程，负责本node）回收内存时，可以先对脏页进行回写（writeback）再进行回收，而直接内存回收只回收干净页。也叫同步回收.
直接内存回收是在当前进程的上下文中进行的，要等内存回收完成才能继续尝试进行分配，所以是阻塞了当前进程的执行，会导致响应延迟增加
如果是在容器里，也就是在某个子memory cgroup 中，那么在分配内存后，还有一个记账（charge）的步骤，就是要把这次分配的内存页记在某个memory cgroup的账上，这样才能控制这个容器里的进程所能使用的内存数量。
在开源社区的linux代码中，如果charge 失败，也就是说，当新分配的内存加上原先的usage超过了limit，就会触发内存回收，try_to_free_mem_cgroup_pages，这个也是同步回收，等同于直接内存回收（发生在当前进程的上下文忠），所以会对应用的响应造成影响（表现为卡顿）。
碎片化
内存碎片严重的话会导致系统hang很久(回收、压缩内存）
尽量让系统的free多一点(比例高一点）可以调整 vm.min_free_kbytes(128G 以内 2G，256G以内 4G/8G), 线上机器直接修改vm.min_free_kbytes会触发回收，导致系统hang住 https://www.atatech.org/articles/163233 https://www.atatech.org/articles/97130
每个zone都有自己的min low high,如下，但是单位是page, 计算案例：
|
|
内存碎片化导致rt升高的诊断
判定方法如下：
- 运行 sar -B 观察 pgscand/s，其含义为每秒发生的直接内存回收次数，当在一段时间内持续大于 0 时，则应继续执行后续步骤进行排查；
- 运行
cat /sys/kernel/debug/extfrag/extfrag_index观察内存碎片指数，重点关注 order >= 3 的碎片指数，当接近 1.000 时，表示碎片化严重，当接近 0 时表示内存不足； - 运行
cat /proc/buddyinfo, cat /proc/pagetypeinfo查看内存碎片情况， 指标含义参考 ，同样关注 order >= 3 的剩余页面数量，pagetypeinfo 相比 buddyinfo 展示的信息更详细一些，根据迁移类型 （伙伴系统通过迁移类型实现反碎片化）进行分组，需要注意的是，当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重，我们需要结合其他工具来排查具体原因，在本文就不做过多介绍了； - 对于 CentOS 7.6 等支持 BPF 的 kernel 也可以运行我们研发的 drsnoop，compactsnoop 工具对延迟进行定量分析，使用方法和解读方式请参考对应文档；
- (Opt) 使用 ftrace 抓取 mm_page_alloc_extfrag 事件，观察因内存碎片从备用迁移类型“盗取”页面的信息。
一个阿里云ECS 因为宿主机碎片导致性能衰退的案例
LVS后面三个RS在同样压力流量下，其中一个节点CPU非常高，通过top看起来是所有操作都很慢，像是CPU被降频了一样，但是直接跑CPU Prime性能又没有问题
原因：ECS所在的宿主机内存碎片比较严重，导致分配到的内存主要是4K Page，在ECS中大页场景下会慢很多
通过 openssl speed aes-256-ige 能稳定重现 在大块的加密上慢很多
小块上性能一致，这也就是为什么算Prime性能没问题。导致慢只涉及到大块内存分配的场景，这里需要映射到宿主机，但是碎片多分配慢导致了问题。
如果reboot ECS的话实际只是就地重启ECS，仍然使用的reboot前分配好的宿主机内存，不会解决问题。重启ECS中的进程也不会解决问题，只有将ECS迁移到别的物理机（也就是通过控制台重启，会重新选择物理机）才有可能解决这个问题。
或者购买新的ECS机型（比如第6代之后ECS）能避免这个问题。
ECS内部没法查看到这个碎片，只能在宿主机上通过命令查看大页情况：
|
|
内存使用分析
pmap
|
|
- Address：占用内存的文件的内存起始地址。
- Kbytes：占用内存的字节数。
- RSS：实际占用内存大小。
- Dirty：脏页大小。
- Mapping：占用内存的文件，[anon] 为已分配的内存，[stack] 为程序堆栈
/proc/pid/
/proc/[pid]/ 下面与进程内存相关的文件主要有maps , smaps, status。
maps： 文件可以查看某个进程的代码段、栈区、堆区、动态库、内核区对应的虚拟地址
smaps: 显示每个分区更详细的内存占用数据，能看到一个动态库被共享了几次
status: 包含了所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻
Java内存使用分析
|
|
We can see two types of memory:
- Reserved — the size which is guaranteed to be available by a host’s OS (but still not allocated and cannot be accessed by JVM) — it’s just a promise
- Committed — already taken, accessible, and allocated by JVM
page fault
内核给用户态申请的内存，默认都只是一段虚拟地址空间而已，并没有分配真正的物理内存。在第一次读写的时候才触发物理内存的分配，这个过程叫做page fault。那么，为了访问到真正的物理内存，page fault的时候，就需要更新对应的page table了。
参考资料
https://www.atatech.org/articles/66885
https://cloud.tencent.com/developer/article/1087455
https://www.cnblogs.com/xiaolincoding/p/13719610.html
https://sunsea.im/rsyslogd-systemd-journald-high-memory-solution.html