四级页表
1.为什么需要四级页表？
在 64 位系统中，虚拟地址空间巨大（理论上 2642^{64}264）。如果只用单级页表，需要维护一个无法想象的巨大页表。采用多级页表可以：
- 按需分配：只映射实际使用的虚拟地址空间
- 节省内存：未使用的地址区间不需要分配页表页
2.虚拟地址划分（48位有效地址）
x86-64 架构（四级页表）使用 48 位有效虚拟地址，高 16 位是符号扩展位：
cpp
┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ 63..48 │ 47..39 │ 38..30 │ 29..21 │ 20..12 │ 11..0 │
│ 符号扩展 │ PGD │ PUD │ PMD │ PTE │ 页内偏移 │
│ (16位) │ (9位) │ (9位) │ (9位) │ (9位) │ (12位) │
└─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
↑ ↑
四级索引 (4 × 9 = 36位) + 偏移 (12位) = 48位为什么是 9 位一级？ 因为页表页大小为 4KB，每个页表项占 8 字节，所以每页可容纳 4096/8=512=292^929个条目。
3.四级页表结构
cpp
CR3 寄存器
│
▼
┌─────────────┐
│ PGD │ Page Global Directory (页全局目录)
│ (512项) │ ──► 每个 PUD 覆盖 512GB
└──────┬──────┘
│
▼
┌─────────────┐
│ PUD │ Page Upper Directory (页上级目录)
│ (512项) │ ──► 每个 PMD 覆盖 1GB
└──────┬──────┘
│
▼
┌─────────────┐
│ PMD │ Page Middle Directory (页中间目录)
│ (512项) │ ──► 每个 PTE 覆盖 2MB
└──────┬──────┘
│
▼
┌─────────────┐
│ PTE │ Page Table Entry (页表项)
│ (512项) │ ──► 每个物理页 4KB
└──────┬──────┘
│
▼
物理页框覆盖范围计算：
| 层级 | 索引位数 | 该级覆盖范围 |
|---|---|---|
| PGD | 9位 | 29×512GB=256TB2^9 \times 512\text{GB} = 256\text{TB}29×512GB=256TB |
| PUD | 9位 | 29×1GB=512GB2^9 \times 1\text{GB} = 512\text{GB}29×1GB=512GB |
| PMD | 9位 | 29×2MB=1GB2^9 \times 2\text{MB} = 1\text{GB}29×2MB=1GB |
| PTE | 9位 | 29×4KB=2MB2^9 \times 4\text{KB} = 2\text{MB}29×4KB=2MB |
4.地址转换流程
cpp
虚拟地址: 0x7FFF_1234_5678_9ABC
步骤1: 从 CR3 获取 PGD 基址（物理地址）
步骤2: 取 bits[47:39] = 0x0FF → PGD[0x0FF] → 得 PUD 基址
步骤3: 取 bits[38:30] = 0x0D2 → PUD[0x0D2] → 得 PMD 基址
步骤4: 取 bits[29:21] = 0x1A2 → PMD[0x1A2] → 得 PTE 基址
步骤5: 取 bits[20:12] = 0x34C → PTE[0x34C] → 得物理页框号
步骤6: 拼接 PFN + bits[11:0] = 0xABC → 物理地址这个遍历过程由 CPU 的 MMU（内存管理单元） 硬件自动完成，对软件透明。
5.大页（Huge Pages）
x86-64 支持通过减少页表层级来实现大页：
| 大页类型 | 大小 | 跳过的页表层级 | 地址划分 |
|---|---|---|---|
| 标准页 | 4KB | 无 | PGD→PUD→PMD→PTE |
| 大页 | 2MB | 跳过 PTE | PMD 的 PS=1，直接指向 2MB 页 |
| 巨页 | 1GB | 跳过 PMD+PTE | PUD 的 PS=1，直接指向 1GB 页 |
5.TLB 与性能优化
每次地址转换需要 4 次内存访问（读四级页表），代价很高。CPU 使用 TLB（转译后备缓冲器） 缓存最近使用的虚拟→物理映射：
- TLB 命中：零额外内存访问，直接得到物理地址
- TLB 未命中：硬件自动遍历页表（Page Walk）
当页表被修改时（如 mmap、munmap、进程切换），需要执行 invlpg 或更新 CR3 来刷新 TLB。
x86-64 四级页表项（PTE）完整解析
1.页表比特位
页表项的物理结构：
在 x86-64 架构下，每一级页表项都是 64 位（8 字节），无论 PGD、PUD、PMD 还是 PTE，格式基本一致，但某些位的含义因层级而异。
- 基础权限位（低 3 位）
| 位 | 名称 | 全称 | 作用 |
|---|---|---|---|
| 0 | P | Present（存在位） | 1 = 该页在物理内存中；0 = 页不在内存，访问触发 #PF（缺页异常） |
| 1 | R/W | Read/Write（读写位） | 1 = 可读写；0 = 只读。写只读页触发 #PF |
| 2 | U/S | User/Supervisor（用户/超级用户位） | 1 = 用户态可访问；0 = 仅内核态（CPL=0,1,2）可访问 |
- 缓存与访问控制位
| 位 | 名称 | 作用 |
|---|---|---|
| 3 | PWT | Page Write Through。1=写透（Write-Through），0=写回（Write-Back） |
| 4 | PCD | Page Cache Disable。1=禁用该页的 CPU 缓存（如 MMIO 内存） |
| 5 | A | Accessed（访问位）。CPU 访问该页后硬件自动置 1，供页回收算法参考 |
| 6 | D | Dirty（脏位）。CPU 对该页执行写操作后硬件自动置 1，换出时需写回磁盘 |
- 高级特性位
| 位 | 名称 | 作用 |
|---|---|---|
| 7 | PS | Page Size（页大小位）。仅在 PUD/PMD 中有效 ： 1 = 该目录项直接指向大页（PMD→2MB，PUD→1GB），不再指向下一级页表 |
| 8 | G | Global（全局位）。1 = TLB 项在 CR3 切换时不刷新（如内核页表），需配合 CR4.PGE |
| 9-11 | A3-A1 | Available（软件可用位）。CPU 不解释，供操作系统自由使用 |
| 12-51 | PFN | Page Frame Number（页框号）。指向下一级页表或物理页框的基地址 |
| 52-62 | --- | 保留位，必须为 0 |
| 63 | XD | Execute Disable（禁止执行位）。1 = 该页不可执行（防止栈/堆上执行 shellcode），需 EFER.NXE |
2.不同层级页表项的差异
虽然四级页表项都是 64 位，但各层级职责不同：
| 层级 | 名称 | 存储内容 | PS=1 时的含义 |
|---|---|---|---|
| PGD | 页全局目录 | PUD 的物理基址 | x86-64 中 PGD 的 PS 位保留必须为 0 |
| PUD | 页上级目录 | PMD 的物理基址 | PS=1 → 1GB 巨页，PFN 指向 1GB 对齐的物理页 |
| PMD | 页中间目录 | PTE 的物理基址 | PS=1 → 2MB 大页，PFN 指向 2MB 对齐的物理页 |
| PTE | 页表项 | 物理页框基址 | PTE 无 PS 位（bit7 为 PAT） |
3.页表项与缺页异常（Page Fault）
当 CPU 发现页表项存在问题时，触发 #PF 异常，错误码（Error Code）保存在栈上：
错误码比特位分析：
| 位 | 含义 |
|---|---|
| P=0 | 页不存在（P=0）或保留位违规 |
| P=1 | 页存在但权限不足（如写只读页） |
| W/R=1 | 写操作导致 |
| U/S=1 | 用户态访问导致 |
| I/D=1 | 取指令导致（NX 位触发） |
| RSVD=1 | 页表项保留位非零（硬件/软件 bug） |
4.页表项与页表页的关系
cpp
┌─────────────────┐
│ 页表页 │ 4KB 物理页
│ (4096 字节) │
│ │
│ ┌───────────┐ │
│ │ PTE[0] │ │ 8字节
│ │ PTE[1] │ │ 8字节
│ │ ... │ │
│ │ PTE[511] │ │ 8字节
│ └───────────┘ │
│ │
│ 512 项 × 8字节 = 4096字节
└─────────────────┘关键点：页表页本身也是一个物理页，由 alloc_page() 分配，并通过 set_pte_at() 等函数填充到上级页表中。
5.总结速查表
| 概念 | 说明 |
|---|---|
| P=0 | 页未映射或已换出，访问触发 #PF |
| R/W=0 | 只读页，写操作触发 #PF |
| U/S=0 | 内核页，用户态访问触发 #PF |
| XD=1 | 不可执行页，取指令触发 #PF（DEP/NX 防护） |
| A=1 | 该页近期被访问，LRU 算法保留 |
| D=1 | 该页被修改过，换出前必须写回 |
| PS=1 (PMD) | 2MB 大页，减少 TLB miss |
| PS=1 (PUD) | 1GB 巨页，适合大内存应用 |
6.解释疑问？
64位虚拟地址下，有效虚拟地址48位，此前提下四级页表的页框号为40位，结合页内偏移映射出一个52位物理地址是否有必要？
回答：有必要，页表每个进程均有一份，物理地址由系统统一管理服务于所有进程，52位物理地址可以允许系统实际管理范围更大的物理内存。
多核多线程下硬件高速缓存与性能优化
1.硬件缓存基础架构
- 三级缓存层级
cpp
┌─────────────────────────────────────────────┐
│ 多核 CPU 芯片 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Core 0 │ │ Core 1 │ │ Core N │ │
│ │ ┌─────┐ │ │ ┌─────┐ │ │ ┌─────┐ │ │
│ │ │ L1i │ │ │ │ L1i │ │ │ │ L1i │ │ │
│ │ │ L1d │ │ │ │ L1d │ │ │ │ L1d │ │ │
│ │ │ L2 │ │ │ │ L2 │ │ │ │ L2 │ │ │
│ │ └──┬──┘ │ │ └──┬──┘ │ │ └──┬──┘ │ │
│ └────┼────┘ └────┼────┘ └────┼────┘ │
│ └─────────────┼─────────────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ L3/LLC │ ← 共享最后一级缓存 │
│ │ (大容量) │ │
│ └────┬────┘ │
│ ▼ │
│ 内存控制器 → 主内存 (DRAM) │
└─────────────────────────────────────────────┘| 层级 | 典型延迟 | 容量 | 共享范围 |
|---|---|---|---|
| L1d/i | 3-4 周期 | 32-64KB | 单核私有 |
| L2 | 10-12 周期 | 256KB-1MB | 单核/双核共享 |
| L3/LLC | 30-50 周期 | 8-64MB | 全核共享 |
- 缓存行（Cache Line）
缓存操作的最小单位是 64 字节（主流 x86-64）：
cpp
┌─────────────────────────────────────────────────────────────┐
│ Cache Line = 64 Bytes = 512 bits │
│ ┌─────────┬──────────────────────────────────────────────┐ │
│ │ Tag + │ Data (64B) │ │
│ │ Status │ ┌────┬────┬────┬────┬────┬────┬────┬────┐ │ │
│ │ Bits │ │8B │8B │8B │8B │8B │8B │8B │8B │ │ │
│ │ │ └────┴────┴────┴────┴────┴────┴────┴────┘ │ │
│ └─────────┴──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘关键原则：即使只读写 1 字节，CPU 也会加载整个 64B 缓存行。这是理解后续所有优化/陷阱的基础。
2.存一致性协议（MESI 及其扩展）
- MESI 协议状态
多核环境下，同一缓存行可能在多个核的 L1/L2 中同时存在。MESI 协议定义了四种状态：
| 状态 | 名称 | 含义 |
|---|---|---|
| M | Modified（修改） | 缓存行被修改，与内存不一致，独占且脏 |
| E | Exclusive（独占） | 缓存行与内存一致，仅当前核持有 |
| S | Shared（共享） | 缓存行与内存一致，多核同时持有 |
| I | Invalid（无效） | 缓存行无效，不可使用 |
- 状态转换与性能影响
cpp
场景：Core 0 持有状态 S 的缓存行，Core 1 写入同一行
Core 0: S ──[收到 RFO]──► I (缓存行失效，下次访问需从内存/L3重载)
Core 1: I ──[写入命中]──► M (获得独占权)
性能代价：
- RFO (Read For Ownership) 跨核广播：~100+ 周期
- 若 Core 0 刚被修改过：还需写回内存（额外延迟）3.伪共享（False Sharing）------ 最隐蔽的性能杀手
- 什么是伪共享？
两个线程操作不同的变量，但这两个变量恰好落在同一个缓存行上：
cpp
缓存行 (64B):
┌─────────────────────────────────────────────────────────────┐
│ thread_A 的计数器 (8B) │ thread_B 的计数器 (8B) │ 填充... │
│ ↑ 频繁读写 ↑ 频繁读写 │
│ └──────── 同一缓存行 ─────────┘ │
└─────────────────────────────────────────────────────────────┘
结果：Core 0 写 → 使 Core 1 的缓存失效 → Core 1 写 → 使 Core 0 失效
形成" ping-pong "效应，性能暴跌 10-100 倍- 解决方案：缓存行对齐 + 填充
cpp
// C/C++：使用对齐属性 + 填充
#define CACHE_LINE_SIZE 64
struct alignas(CACHE_LINE_SIZE) PaddedCounter {
long long value;
char padding[CACHE_LINE_SIZE - sizeof(long long)]; // 56 字节填充
};
PaddedCounter counters[NUM_THREADS]; // 每个计数器独占一行验证工具：
cpp
# perf 检测缓存一致性事件
perf stat -e cache-misses,L1-dcache-load-misses,offcore_response \
./your_program4.内存序与可见性（Memory Ordering）
- 硬件重排序
现代 CPU 为了性能会对指令进行乱序执行和内存访问重排序：
cpp
程序顺序： 实际执行可能：
Store A Store B
Store B ──► Store A (Store-Store 重排)
Load C Load Cx86-64 属于 TSO（Total Store Order） 架构，只允许：
- Store-Load 重排序（Store Buffer 导致）
- 不允许 Load-Load、Load-Store、Store-Store 重排
ARM/RISC-V 属于 弱内存模型，四种重排序都可能发生。
- 内存屏障（Memory Barrier/Fence）
cpp
// C11 内存序
atomic_store(&flag, 1, memory_order_release); // 发布语义
// ... 确保之前的写对后续读者可见 ...
atomic_load(&flag, memory_order_acquire); // 获取语义
// ... 确保看到 flag=1 后，能看到发布者之前的所有写 ...| 屏障类型 | 作用 | 开销 |
|---|---|---|
memory_order_relaxed |
无同步，仅原子性 | 最低 |
memory_order_acquire |
读屏障，后续读写不能提前 | 中等 |
memory_order_release |
写屏障，之前读写不能延后 | 中等 |
memory_order_seq_cst |
全序，最强一致性 | 最高（可能触发锁总线） |
优化原则：能用 acquire/release 就不用 seq_cst，后者可能触发跨核缓存同步。
5.NUMA 架构与本地性优化
- NUMA 拓扑
cpp
Node 0 (Socket 0) Node 1 (Socket 1)
┌─────────────────────┐ ┌─────────────────────┐
│ Core0 Core1 Core2 │ │ Core4 Core5 Core6 │
│ Core3 │ │ Core7 │
│ ┌───────────────┐ │ │ ┌───────────────┐ │
│ │ Local │ │ │ │ Local │ │
│ │ Memory │ │ │ │ Memory │ │
│ │ (128GB) │ │ │ │ (128GB) │ │
│ └───────────────┘ │ │ └───────────────┘ │
└─────────────────────┘ └─────────────────────┘
│ │
└────────── QPI/UPI ─────────────┘
(跨节点互联)
访问本地内存：~80ns
访问远端内存：~130ns（+60% 延迟）- NUMA 优化策略
cpp
# 1. 查看 NUMA 拓扑
numactl --hardware
# 2. 绑定线程到指定 NUMA 节点
numactl --cpunodebind=0 --membind=0 ./program
# 3. 在代码中使用 libnuma
#include <numa.h>
numa_run_on_node(0); // 线程绑定到 Node 0
void *ptr = numa_alloc_onnode(size, 0); // 在 Node 0 分配内存Linux 内核自动优化：
- numa_balancing：自动迁移热页到访问者所在节点
- 透明大页（THP）减少 TLB miss，同时提升 NUMA 局部性
6.无锁并发与缓存优化
- 无锁数据结构
锁竞争会导致线程阻塞和缓存失效，无锁编程通过原子操作避免：
cpp
// 无锁队列（Michael-Scott Queue）核心思想
// 使用 CAS (Compare-And-Swap) 替代互斥锁
bool enqueue(lock_free_queue_t *q, void *data) {
node_t *node = new_node(data);
node_t *tail;
do {
tail = atomic_load(&q->tail, memory_order_acquire);
node_t *next = atomic_load(&tail->next, memory_order_acquire);
if (tail != atomic_load(&q->tail)) continue; // ABA 检查
if (next == NULL) {
// CAS：如果 tail->next 仍为 NULL，则设为 node
if (atomic_compare_exchange_weak(&tail->next, &next, node))
break;
} else {
// 帮助推进 tail 指针
atomic_compare_exchange_weak(&q->tail, &tail, next);
}
} while (1);
atomic_compare_exchange_weak(&q->tail, &tail, node);
return true;
}- Read-Copy-Update (RCU)
Linux 内核广泛使用的读多写少优化技术：
cpp
读端（无锁、无原子操作、无内存屏障）：
rcu_read_lock();
data = rcu_dereference(global_ptr); // 仅一次读
// 使用 data...
rcu_read_unlock();
写端（延迟释放）：
new_data = kmalloc(...);
*new_data = ...;
rcu_assign_pointer(global_ptr, new_data); // 原子更新指针
synchronize_rcu(); // 等待所有读端完成
kfree(old_data); // 安全释放旧数据RCU 核心优势：读端零开销（不污染缓存、不触发一致性协议），适合配置表、路由表等读多写少场景。
7.数据布局与访问模式优化
- 结构体字段重排（AOS vs SOA）
cpp
// ❌ 糟糕：Array of Structs，导致缓存行跳跃
struct Particle {
float x, y, z; // 位置
float vx, vy, vz; // 速度
float mass; // 质量
int id; // ID
char flags; // 标志
};
// 大小：29B → 对齐后 32B，但访问模式混乱
// ✅ 优化：Structure of Arrays，向量化友好
struct Particles {
float *x, *y, *z;
float *vx, *vy, *vz;
float *mass;
int *id;
char *flags;
};
// 同一属性的数据连续存储，缓存预取友好- 预取指令（Prefetch）
cpp
// GCC/Clang
#include <immintrin.h>
for (int i = 0; i < n; i++) {
// 预取 8 个迭代后的数据（L1 缓存）
__builtin_prefetch(&data[i + 8], 0, 3); // 读, 局部性高
process(data[i]);
}8.线程绑定与调度优化
8.1.CPU 亲和性（Affinity）
cpp
// POSIX 线程绑定
#define _GNU_SOURCE
#include <sched.h>
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(4, &cpuset); // 绑定到 Core 4
pthread_setaffinity_np(thread, sizeof(cpuset), &cpuset);为什么需要绑定？
- 避免线程在核间迁移导致缓存失效
- 将计算密集型线程与 I/O 线程分离到不同核心
- 超线程（SMT）场景下，避免将两个重负载线程放到同一物理核的两个逻辑核
8.2.超线程（SMT/Hyper-Threading）考量
cpp
物理 Core 0:
┌─────────────────────────────────────────┐
│ ┌──────────┐ ┌──────────┐ │
│ │ 逻辑核 0 │ │ 逻辑核 1 │ │
│ │ (L1/L2) │ │ (L1/L2) │ 共享执行单元 │
│ └──────────┘ └──────────┘ │
│ 共享 L1/L2、执行端口 │
└─────────────────────────────────────────┘
策略：
- 两个重负载线程 → 放到不同物理核（避免资源争抢）
- 一个重负载 + 一个轻负载（如监控线程）→ 可共享同一物理核9,性能监控与诊断工具
| 工具 | 用途 | 关键指标 |
|---|---|---|
perf |
硬件 PMU 事件采样 | cache-misses, cache-references, L1-dcache-load-misses |
perf c2c |
检测伪共享 | HITM（Hit Modified）事件 |
Intel VTune |
深度微架构分析 | 内存带宽、缓存命中率、前端/后端阻塞 |
numastat |
NUMA 统计 | 本地/远端内存分配比例 |
toplev |
自顶向下性能分析 | 识别前端 bound、后端 bound、 bad speculation |
- 使用 perf c2c 检测伪共享
cpp
# 1. 记录 HITM 事件
perf c2c record -a --ldlat=50 -- ./program
# 2. 生成报告
perf c2c report
# 输出示例：
# HITM Rmt Lcl Off Symbol Shared Object
# ---- --- --- --- ------ -----------
# 15.2% 75% 25% 32 counter::increment ./program
# → 说明 counter::increment 有大量跨核修改命中10.优化策略速查表
| 问题 | 症状 | 解决方案 |
|---|---|---|
| 伪共享 | 多线程线性扩展性差，CPU 利用率低但 perf 显示大量 cache-misses |
缓存行对齐 + 填充（alignas(64)） |
| NUMA 远端访问 | 内存延迟高，numastat 显示大量 other_node |
numactl 绑定，使用 libnuma 本地分配 |
| 锁竞争 | 线程大量时间花在 futex/pthread_mutex_lock |
细粒度锁、无锁结构（CAS）、RCU、per-CPU 变量 |
| 缓存未命中 | L1-dcache-load-misses 比例 > 5% |
数据预取、SOA 布局、循环分块（Tiling） |
| 内存序过强 | 原子操作成为瓶颈 | 降级到 acquire/release，避免 seq_cst |
| 线程迁移 | 缓存热数据频繁失效 | pthread_setaffinity_np 绑定核心 |
11.总结
多核多线程下的缓存优化核心围绕一个原则：减少跨核缓存一致性流量，最大化数据局部性。
- 避免伪共享：这是最容易被忽视、优化收益最大的点
- 尊重 NUMA 拓扑：本地内存访问延迟远低于远端
- 谨慎使用内存序：过强的序会触发昂贵的跨核同步
- 无锁优于阻塞锁：CAS 循环通常比互斥锁+上下文切换更快
- 数据布局决定缓存效率：SOA、对齐、预取是基本功
最终，所有优化都应基于 实际测量（perf、VTune），而非假设。缓存行为高度依赖于具体的工作负载和处理器微架构。