1. 同一个地址，两块内存：先把"虚拟地址"这件事看实
我最早对进程地址空间产生真正的困惑，是在读一段打印指针的代码时。父子两个进程里，同一个全局变量的&出来的值一模一样，子进程把它改成 100，父进程读出来还是 42。当时的第一反应是"编译器在骗人"，第二反应是"那这个地址到底指向什么"。后来才明白，printf("%p")打出来的从来不是物理内存的坐标，而是当前进程私有地址空间里的一份"门牌号"，门牌号后面挂的是哪块真实内存，由内核那一层的页表决定，进程自己没资格知道。
这个认知一旦建立，后面很多东西就顺了：fork为什么能瞬间完成、malloc为什么能一口气"分配"几个 G、共享库为什么在几十个进程里只占一份物理内存、/proc/pid/maps里那一堆乱七八糟的地址段到底在描述什么。反过来，如果不接受"地址是虚拟的"这个前提，很多现象会被强行解释成"内核优化""编译器捣鬼"，越解释越乱。
下面这段代码建议你真跑一遍，它成本极低，但能一次性把几个关键事实摆在你面前：栈、堆、全局区地址分布在明显不同的区间；fork之后父子进程看到的地址完全一致；但对同一地址的写入互相看不见。
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> int g_val = 42; int main(void) { int stack_val = 7; int *heap_val = malloc(sizeof(int)); *heap_val = 99; printf("g_val @ %p\n", (void *)&g_val); printf("stack @ %p\n", (void *)&stack_val); printf("heap @ %p\n", (void *)heap_val); pid_t pid = fork(); if (pid == 0) { printf("[child ] 修改前: %d %d %d\n", g_val, stack_val, *heap_val); g_val = 100; stack_val = 200; *heap_val = 300; printf("[child ] 地址: %p %p %p\n", (void *)&g_val, (void *)&stack_val, (void *)heap_val); printf("[child ] 修改后: %d %d %d\n", g_val, stack_val, *heap_val); _exit(0); } wait(NULL); printf("[parent] 地址: %p %p %p\n", (void *)&g_val, (void *)&stack_val, (void *)heap_val); printf("[parent] 数值: %d %d %d\n", g_val, stack_val, *heap_val); free(heap_val); return 0; }1.1 地址空间不是一块内存，是一份"映射承诺"
把上面程序跑出来的结果看一眼就清楚了：子进程打印的&g_val和父进程完全一致，但值不同。这说明进程地址空间不是物理内存的切片，而是一张描述"哪些虚拟地址合法、映射到哪里"的登记表。Linux 把这张表里连续的、属性相同的一段叫做 VMA（virtual memory area），你在/proc/<pid>/maps里看到的每一行就是一个 VMA。
这份登记表本身几乎不占多少真实内存，所以一个进程"拥有"4GB 甚至 128TB 的地址空间并不稀奇，真正消耗资源的只有那些已经落到物理页上的部分。这也解释了一个新手常见的疑惑：malloc(1GB)返回成功，ps里的 RSS 却没涨——因为登记表上写了一条"这段地址属于你，用的时候再说"，物理页一张都没给。等真去写第一字节，内核才发现"哦，页表项是空的"，触发一次缺页中断，才把物理页补上。这套机制叫按需分页（demand paging），是虚拟地址方案顺带送出来的能力。
1.2 "虚拟"不是假的，它是有硬件的
很多人把"虚拟地址"理解成软件层面的抽象，其实它一半活在 CPU 里。CPU 执行一条访存指令时，拿到的永远是虚拟地址，真正把它翻译成物理地址的动作由MMU（内存管理单元）完成，翻译依据就是页表基址寄存器（x86-64 上是 CR3）指向的那棵页表树。也就是说，只要页表没建好，哪怕物理内存空着一大片，程序照样跑不过去——这不是内核"不给"，而是硬件层面翻译失败，直接抛页错误。
理解这一点很关键：地址空间的切换本质上就是 CR3 的切换。进程切换时，内核把新进程的页表基址写进 CR3，一瞬间整个地址空间的"世界观"就换了。所以两个进程即便打印出同一个地址，它们各自的页表把这一页映射到不同物理页，谁也看不见谁。这就是为什么父子进程能"地址相同、数据独立"。
2. 这层中间层到底在替谁挡事：地址空间存在的四个硬理由
如果只把虚拟地址当成"一种实现便利"，那理解会停留在表面。它真正解决的是四个绕不过去的问题，缺了任何一个，现代操作系统都撑不住。我习惯把它们拆成四件事讲，因为它们对应四种完全不同的失效场景。
2.1 隔离：一个越界的指针碰不到别人的数据
没有虚拟地址的年代，程序直接操作物理地址，一个写错的指针可以把隔壁程序的内存覆盖掉，甚至写到内核数据结构上。有了地址空间之后，越界访问最坏的结果是触发一次段错误把当前进程杀掉——因为那个地址在当前进程的页表里压根没有有效页表项，MMU 直接拒绝。邻居的物理页即便就在旁边几个字节处，你的页表里没有指向它的项，你连它的门牌号都拿不到。
这种隔离的粒度是页（通常 4KB）。同一页内的越界仍然可能改到自己进程的其他数据，所以它防的是"跨进程破坏"，不是"程序自身 bug"。这个边界要说清楚，不然容易产生不切实际的期待。
2.2 连续假象：让每个进程都以为自己独占一大段连续内存
真实物理内存是碎片化的：跑一会儿之后，能用的空闲块可能是一堆散落的小区域。但程序员的思维模型是"我有一个从 0 开始的连续地址空间"。虚拟地址恰好能把这两者接上——你可以拿到一段虚拟上连续的 1GB 区域，它背后映射到几百个物理上不连续的 4KB 页，程序完全无感。
这个能力对分配器极其重要。malloc拿到一块大的虚拟区域之后，可以在内部随意切分，不用操心物理碎片。堆能"长大"也是这个道理：增长的是 VMA 的上界，不是真的搬了一块内存过去。
2.3 重定位：程序不用关心自己会被放在哪
可执行文件在链接时用的是一套固定的虚拟地址假设（比如代码段从0x400000起），加载时内核只要把那几段映射到任意物理页上即可，程序内部的绝对地址引用全部不用改。这带来了两个直接好处：一是位置无关，同一个可执行文件在不同机器、不同进程里可以落到不同物理位置；二是共享，libc 的代码段可以被几百个进程映射到各自的地址空间，但物理上只有一份。
2.4 共享与延迟分配：省下来的都是真金白银
共享这一条值得单独说。同一个共享库的只读代码段，在 50 个进程里被映射 50 次，物理页只有一份，页表项各自指向它。省下的内存不是小数目——一个稍大的程序，光动态库映射就可能上百 MB。延迟分配则体现在另一头：从未被写过的匿名页可以全部指向同一个"零页"（zero page），只读共享，等你真写了才给你拷一份。
| 需求 | 没有虚拟地址的做法 | 有地址空间之后 |
|---|---|---|
| 进程隔离 | 靠约定和自觉，越界即灾难 | 页表项缺失，硬件直接拦截 |
| 连续内存 | 必须找到一块足够大的物理连续区 | 虚拟连续即可，物理随便散 |
| 程序加载 | 每次都要重定位所有绝对地址 | 映射到任意物理页，代码不用改 |
| 库共享 | 每个进程各加载一份 | 只读段物理共享，页表各指一份 |
| 内存分配 | 立即占用真实内存 | 先记账，写入时才落实 |
这张表里最后一行是我认为最容易被低估的。它意味着"内存充足"这个判断标准变了：一个进程报告占用 2GB 虚拟内存，可能实际只碰了 30MB 物理页。做容量规划时盯着 VSZ 会被吓到，看 RSS 和 PSS 才有意义。
3. 页表的真实长相：多级索引、页表项位域和一次地址翻译的全过程
页表这个词容易让人联想到"一张大表格"，实际上现代 x86-64 上它是一棵四层的树，每一层都是一张 4KB 的表，装 512 个 8 字节的表项。理解它的结构，才能明白"为什么查一个地址要访存四次"以及"为什么多级页表反而更省内存"。
3.1 先算一笔账：单级页表为什么活不下去
假设用最朴素的设计，一个页表项对应一个 4KB 页。32 位地址空间是 4GB，除以 4KB 得 1048576 个页，每个表项 4 字节，一张完整页表就是4MB。这还只是 32 位、还只是一个进程。开 200 个进程，光页表就 800MB，而且大部分表项是空的——一个进程实际用到的地址区间往往集中在几 MB 内，剩下的 99% 都是无效项。
64 位更夸张。x86-64 实际使用 48 位虚拟地址，页数达到 2^36，约 687 亿项，每项 8 字节，单级页表要512GB。这不是"有点浪费"，是根本不可能。多级页表就是为这个问题设计的：不存在的地址区间，上层表项直接置空，下面的整张表根本不用分配。
3.2 48 位虚拟地址被切成五段
x86-64 的地址翻译把 48 位切成 4 个 9 位索引加 1 个 12 位偏移：
| 位段 | 名称 | 作用 |
|---|---|---|
| 47:39 | PML4 索引 | 从 CR3 指向的顶层表取第 N 项 |
| 38:30 | PDPT 索引 | 从 PDPT 表取第 N 项 |
| 29:21 | PD 索引 | 从页目录取第 N 项 |
| 20:12 | PT 索引 | 从页表取第 N 项 |
| 11:0 | 页内偏移 | 4KB 页内的字节位置 |
每一级 9 位刚好索引 512 个表项，和 4KB / 8 字节 = 512 严丝合缝。翻译过程就是：CR3 → PML4 表 → 取一项得到 PDPT 表物理地址 → 再取一项得到 PD 表物理地址 → 再取一项得到 PT 表物理地址 → 最后取到页框地址，加上 12 位偏移，得到物理地址。一次寻址，最多四次访存，这就是多级页表的代价。
省内存的效果也很直观：一个进程如果只用了低 4MB 左右的地址，PML4 只需要 1 项、PDPT 1 项、PD 1 项就能覆盖，PT 可能几张。整套结构加起来通常几十 KB 到几 MB，和单级方案的 512GB 完全不在一个量级。
3.3 页表项里那些决定行为的位
页表项不止存物理页号，低 12 位塞满了控制位。这些位是理解 COW、权限、缓存行为的钥匙：
| 位 | 名称 | 含义 |
|---|---|---|
| 0 | P (Present) | 为 0 时访问触发缺页，是"按需分页"的总开关 |
| 1 | R/W | 0 只读，1 可写。写时拷贝就是靠清这一位实现的 |
| 2 | U/S | 0 仅内核可访问，1 用户态可访问 |
| 3 | PWT | 页级写穿透，影响缓存策略 |
| 4 | PCD | 页级禁用缓存，常用于 MMIO 区域 |
| 5 | A (Accessed) | 被访问过，内核做页回收时的重要参考 |
| 6 | D (Dirty) | 被写过，决定换出时是否需要回写 |
| 7 | PS (Page Size) | 置 1 表示这是个大页，指向 2MB 或 1GB 页 |
| 8 | G (Global) | 全局页，切换 CR3 时不刷 TLB |
| 63 | NX | 禁止执行，栈和堆上的代码跑不起来靠它 |
看这张表就能理解不少安全机制：栈溢出攻击为什么需要 ROP 这种绕法，因为 NX 位让栈上的 shellcode 直接执行失败；内核为什么能挡住用户态访问内核地址，因为 U/S 位为 0，加上 SMAP/SMEP 的配合。
3.4 TLB 与页表遍历：那些看不见的开销
四级遍历意味着每次访存理论上要五次内存访问（四次查表加一次取数据），性能上不可接受。所以 CPU 内置了TLB，缓存最近的虚拟页到物理页的翻译结果。命中时零额外开销，未命中才走硬件页表遍历（page walk）。
这带来几个实际影响。第一，进程切换会污染 TLB，因为不同进程的页表不同，同一个虚拟页翻译结果不一样。x86 提供 PCID 特性，可以给 TLB 项打上地址空间标签，避免全量刷新——这也是为什么现代内核切换进程没那么贵。第二，大页能显著减少 TLB 压力。4KB 页下，覆盖 2MB 内存需要 512 个 TLB 项；用 2MB 大页只要 1 项。这也是透明大页（THP）存在的核心动机，但它在 COW 场景下会带来副作用，后面第 4 章会讲。
还有一个容易被忽略的数字：/proc/<pid>/status里的VmPTE字段就是页表本身占用的内存。一个跑了很久、内存碎片化严重的进程，这个值可能达到几十 MB，这部分开销不计入 RSS，容易被漏掉。
4. fork 之后父子进程共享物理页：写时拷贝的完整链路
fork是我认为最能体现虚拟地址设计精妙的地方。一个几十 GB 的进程，fork出来只要微秒级，然后把子进程execve掉——整个过程几乎没搬过数据。能做到这一点，靠的就是写时拷贝（Copy-on-Write，COW）。
4.1 fork 复制的到底是什么
新手容易以为fork复制了进程的全部内存。实际上内核做的是：复制task_struct、复制mm_struct（地址空间的描述），然后复制页表——注意是复制页表项，不是复制页表项指向的数据页。新页表里的每一项仍然指向父进程原来的物理页，然后关键的一步来了：内核把父子双方这些页表项的R/W 位都清成只读，同时给这些物理页的引用计数加一。
于是fork返回的那一刻，父子进程的页表长得几乎一样，指向同一批物理页，但都标着"只读"。任何一方想写，硬件立刻报页错误，内核接手处理。这就是为什么fork的开销和进程内存大小基本无关——搬的是元数据，不是数据。
这里有个细节值得注意：不是所有页都会走 COW。共享库的只读代码段本来就是只读的，不需要额外处理；而某些内核页（比如零页）本身就不能写。内核在copy_page_range里会判断，只对可写的私有页做"降权"操作。
4.2 一次写入引发的完整链路
假设子进程执行buf[0] = 2，而这个页还和父进程共享着。硬件走到这一页，发现 R/W 位是 0，触发一个保护性页错误（protection fault，错误码里 W 位为 1、P 位为 1，和普通缺页区分开）。内核的缺页处理入口根据错误码判断这是写保护错误，交给do_wp_page。
do_wp_page的核心判断只有一个：这个物理页现在还有几个人在用。它看page->_refcount（有多少人持有这个页的引用）：
- 如果计数为 1，说明只剩当前进程在用（父进程可能已经退出或者自己先复制过了），那还复制什么？直接把页表项的写权限恢复，原地写入，一次拷贝都不做。这个优化叫reuse，在大量
fork后父进程先退出的场景里命中率很高，是实打实的性能提升。 - 如果计数大于 1，说明还有别人共享。内核分配一张新物理页，把原页内容按页粒度
memcpy过去，更新当前进程页表项指向新页并恢复可写，同时把旧页的引用计数减一。
复制完成之后，当前进程继续执行那条写指令，硬件重新翻译，这次成功。整个过程对用户程序完全透明，除了那一小段时间开销。
4.3 引用计数决定一切：共享页什么时候才真释放
理解 COW 必须先理解_refcount和_mapcount这两个计数。_refcount是"有多少引用指向这个页"，包含页表映射、内核内部持有等；_mapcount更具体，是"有多少个页表项映射了这个页"。munmap或进程退出时，_mapcount减一，减到 -1 说明没有页表映射了，页就可以回收；_refcount归零才真正回到伙伴系统。
这套计数出错会引发很隐蔽的问题：计数偏高，页永远释放不掉，表现为内存泄漏；计数偏低，页被提前释放，表现为数据被莫名覆盖、随机崩溃，而且往往隔很久才复现。所以内核里page_add_new_anon_rmap、page_remove_rmap这类函数的配对关系非常严格。
4.4 大页与 COW 的冲突：2MB 粒度的复制尖刺
透明大页（THP）默认会把相邻的匿名页合并成 2MB 大页，这对 TLB 命中率是好事。但它和 COW 撞在一起会出问题：COW 的复制粒度是页，如果这一页是 2MB 大页，那么哪怕你只写了一个字节，内核也要复制整个 2MB。
在 fork 密集的场景里这个代价很扎眼。比如一个父进程占了 4GB 内存，fork之后子进程只改动几百字节，理论上只该复制几个 4KB 页；但如果这些页是大页，实际可能复制出几十 MB。表现为延迟毛刺、内存曲线突然起飞。排查这类问题要看/proc/<pid>/smaps里的AnonHugePages字段，如果它和Private_Dirty同步暴涨，基本可以确认。
规避手段是给敏感区域打标记：
#include <sys/mman.h> /* 对某段缓冲区禁用透明大页，代价是 TLB 未命中变多， 但 COW 的复制粒度稳定在 4KB */ madvise(buf, len, MADV_NOHUGEPAGE);也可以在进程级别通过/sys/kernel/mm/transparent_hugepage/enabled调整策略，但那会影响全局，生产环境一般用madvise做局部控制。
5. 在真实机器上把页表和COW"看"出来
理论讲到这里已经能自洽了，但我一直觉得这东西不亲手看一眼不算真懂。下面这套方法我在排查内存异常时反复用，全部基于/proc，不需要额外工具，任何一台 Linux 都能跑。
5.1 maps 和 smaps：读出 VMA 与共享/私有内存
先起一个进程，看它的地址空间布局：
# 随便起一个常驻进程作为观察对象 sleep 600 & PID=$! cat /proc/$PID/maps输出每一行是"起始-结束 权限 偏移 设备 inode 路径"，权限位里的p表示私有、s表示共享，r/w/x是读写执行。你能清楚看到代码段（r-xp）、只读数据（r--p）、数据段（rw-p）、堆、若干rw-p的匿名段（线程栈、malloc大块）、动态库映射。
smaps是maps的加强版，每个 VMA 下面跟一组统计：
grep -E "^(Rss|Pss|Shared_Clean|Shared_Dirty|Private_Clean|Private_Dirty|Anonymous|AnonHugePages):" \ /proc/$PID/smaps | head -40这几个字段的区别值得记牢：Shared_Clean是共享且没被改过的页（典型的共享库代码段）；Private_Dirty是私有且被写过的页，COW 复制出来的页全部落在这里；Pss是"按共享比例分摊后的内存"，是判断真实内存占用的最佳指标；Rss只是"驻留页总数"，共享部分会被重复计算。
5.2 pagemap 与 mincore：验证两个地址是否指向同一物理页
想看虚拟地址到物理页的映射，/proc/<pid>/pagemap是唯一入口。每 8 字节对应一个虚拟页，bit 63 表示是否驻留，bits 0-54 是物理页号（PFN）。注意从内核 4.0 起，非特权用户读到的 PFN 一律是 0，必须带CAP_SYS_ADMIN才能看到真实值。
#include <stdio.h> #include <stdint.h> #include <unistd.h> #include <fcntl.h> static uint64_t read_pagemap(pid_t pid, uintptr_t vaddr) { char path[64]; snprintf(path, sizeof(path), "/proc/%d/pagemap", pid); int fd = open(path, O_RDONLY); if (fd < 0) return 0; off_t off = (vaddr / 4096) * 8; uint64_t entry = 0; if (pread(fd, &entry, 8, off) != 8) entry = 0; close(fd); return entry; } /* 判断某地址是否驻留物理内存，以及 PFN（需足够权限） */ int probe(pid_t pid, void *p) { uint64_t e = read_pagemap(pid, (uintptr_t)p); int present = (e >> 63) & 1; uint64_t pfn = e & ((1ULL << 55) - 1); printf("vaddr=%p present=%d pfn=%llu\n", p, present, (unsigned long long)pfn); return present; }如果权限够，你可以在fork之后分别读父子进程同一个虚拟地址的 PFN，会发现两者完全一样——这就是共享物理页的直接证据。子进程写入之后再读一次，PFN 变了，而父进程的没变。这个"变了/没变"的对比，比任何文字解释都直观。
mincore(2)是另一个轻量工具，只告诉你"这一页在不在内存里"，不需要权限：
unsigned char vec[1]; mincore(addr, 4096, vec); /* vec[0] & 1 为 1 表示在内存，0 表示不在（待换入或未分配） */用它可以在malloc之后、写之前、写之后三个时间点分别检查，完整看到"按需分页"的发生过程。
5.3 用时间差测出 COW 的复制代价
想量化 COW 的成本，最土但最有效的办法是计时。下面这段程序分配 256MB，fork之后子进程逐页写，测总耗时：
#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/wait.h> #include <sys/time.h> static double now_ms(void) { struct timeval tv; gettimeofday(&tv, NULL); return tv.tv_sec * 1000.0 + tv.tv_usec / 1000.0; } int main(void) { const size_t pages = 64 * 1024; /* 64K 页 = 256MB */ char *buf = malloc(pages * 4096UL); memset(buf, 1, pages * 4096UL); /* 先全部落到物理页上 */ pid_t pid = fork(); if (pid == 0) { double t0 = now_ms(); for (size_t i = 0; i < pages; i++) { buf[i * 4096UL] = 2; /* 每页写一个字节，触发 COW */ } fprintf(stderr, "子进程写入 %zu 页，耗时 %.2f ms\n", pages, now_ms() - t0); _exit(0); } wait(NULL); free(buf); return 0; }跑下来你会看到耗时明显高于"直接写自己内存"的基线，差值就是页错误处理和 memcpy 的开销。想看细节就用perf stat -e page-faults,minor-faults，或者strace -c -f数一下mprotect/缺页相关系统调用的次数。
这里有个实测心得：第一次跑的数往往不准，因为页可能还没完全驻留；建议先memset预热、跑三轮取中间值。另外如果开着 THP，256MB 会被合并成 128 个 2MB 大页，耗时曲线会呈现明显的台阶状，这时候用madvise(MADV_NOHUGEPAGE)关掉再测，数字会平缓很多。
5.4 用 smaps 观察 COW 的发生过程
最直观的观察方法是在三个时间点各抓一次smaps：
PID=<你的进程号> # 时间点1：fork 之前 grep -E "^(Shared_Clean|Private_Dirty):" /proc/$PID/smaps | awk '{s[$1]+=$2} END {for(k in s) print k, s[k]" kB"}'| 阶段 | Shared_Clean | Private_Dirty | 说明 |
|---|---|---|---|
| fork 前 | 少量（共享库） | 全部已写匿名页 | 私有内存都是干净独享的 |
| fork 后未写 | 显著上升 | 基本不变 | 原私有页变成"共享只读" |
| 子进程写入后 | 略降 | 明显上升 | 复制出的新页计入 Private_Dirty |
这张表的数值变化是 COW 最硬的证据。如果"fork 后未写"这一步Shared_Clean没涨，说明页压根没被标记共享，那你观察的对象可能不是fork出来的子进程，或者内核做了别的处理，需要重新核对。
6. 那些年踩过的认知坑：关于地址空间和COW的六个误区
理论能自洽不代表理解到位，下面这几条都是我或者身边的人真真切切判断错过的，列出来供对照。
6.1 "地址相同就是同一块内存，地址不同就是不同内存"
前半句和后半句都错。地址相同但分属不同进程，页表不同，指向的物理页可以完全不同；同一进程内两个不同的虚拟地址，也可能通过mmap映射到同一物理页——这在文件映射里很常见，一块文件同时被映射两次，写其中一个地址另一个地址能看到变化，但地址值完全不同。
判断是否同一物理页的唯一可靠方法是查 PFN，不是比地址。
6.2 "free 之后内存就还给系统了"
free只是把内存还给分配器，分配器可能留着这块不还给内核，下次malloc直接复用，省一次brk/mmap系统调用。所以进程的 RSS 可能在大量free之后纹丝不动。真正还给内核靠munmap或者madvise(MADV_DONTNEED)，glibc 对大块（默认超过M_MMAP_THRESHOLD，通常 128KB）走mmap的那部分会直接munmap，小块走brk的会被缓存。
想强制归还，用malloc_trim(0)或者在分配器层面调M_TRIM_THRESHOLD。不过我的建议是别急着还，因为还了之后下次再要又得缺页，一进一出反而更慢。
6.3 "写时拷贝只有 fork 会用"
fork是最典型的场景，但不是唯一。mmap文件时用MAP_PRIVATE映射，写操作默认就是 COW 语义——你改的只是自己页表指向的那份拷贝，文件本身不变。这类映射的页在smaps里计入Private_Dirty，关闭或munmap时直接丢弃，不会回写。
另一个场景是容器镜像的分层文件系统，多个容器共享底层只读层，写的时候复制到上层，原理完全一样，只是发生在文件系统层面。
6.4 "虚拟内存就是 swap"
这是老一辈留下来的说法，因为早期 Windows 的"虚拟内存"对话框确实就是在配 swap 文件大小。在今天的内存管理语境里，虚拟内存指的是地址翻译这一整套机制，swap只是页回收的一个去处，而且现代机器上很多场景是禁用或极少用 swap 的。
把这两个概念混在一起，会导致对 VSZ 的严重误判——一个进程 VSZ 几十 GB 不代表它要占几十 GB 磁盘做 swap，那只是预留的虚拟地址范围。
6.5 "页表越小越好，多级页表一定更省"
多级页表在"地址稀疏"的情况下省内存，但在"地址密集"的情况下反而可能比单级方案多占——因为多了中间层的表。而且每次 TLB 未命中的开销，多级是四次访存，单级只有一次。
这就是为什么大页机制存在：用 2MB 页时，平稳覆盖同样内存只需要 1/512 的页表项，遍历层数也少一层。内存密集型的服务开启 THP 后性能提升，主要来自 TLB 命中率，而不是页表本身的空间节省。
6.6 fork 密集场景的两条实用规避
一条是用posix_spawn或vfork+exec替代fork。fork之后立刻exec的场景，中间那一大堆 COW 处理纯属浪费。posix_spawn在大多数实现里会走clone(CLONE_VM | CLONE_VFORK)，子进程和父进程共用地址空间直到exec，省掉了整个页表复制过程。
另一条是控制大页范围。前面说过，THP 会把 COW 的复制粒度从 4KB 放大到 2MB。在内存大、fork频繁的服务里，我会给那些"父进程不写、子进程会写"的缓冲区显式加上MADV_NOHUGEPAGE，牺牲一点 TLB 效率换掉那个不可预测的复制尖刺，实测下来延迟分位数改善明显。
再补一个小经验：/proc/<pid>/status里的VmPTE值得加到监控里。它反映页表自身的内存开销，很多时候进程 RSS 稳定但整体内存缓慢上升，罪魁祸首就是页表膨胀，而这个指标在常规监控面板里经常是缺席的。
