1
虚拟地址空间: 0x00000000 - 0xFFFFFFFF (4GB)
2
页面大小: 4KB = 4096 字节
3
页面数量: 4GB / 4KB = 1,048,576 页
4

5
虚拟地址结构（以 32 位系统为例）：
6
┌──────────────┬───────────────┐
7
│   页号 (20位) │ 页内偏移 (12位) │
8
└──────────────┴───────────────┘
9
  2^20 = 1M 页  2^12 = 4KB 偏移

1
假设进程分配了 N 个页面，每个页面平均浪费一半：
2
- 4KB 页：平均浪费 2KB/页
3
- 64KB 页：平均浪费 32KB/页
4

5
对于大量小对象（如文件元数据、网络连接缓冲区），
6
浪费更严重。

1
# 64 位 Linux 的虚拟地址空间
2
# 典型配置：48 位虚拟地址 = 256 TB
3
# 4KB 页：256TB / 4KB = 64G 页表项
4
# 如果全部映射，页表本身需要 ~512GB！
5

6
# 这就是为什么 x86_64 使用四级页表
7
# 每级只映射实际使用的部分，避免分配完整页表

1
# 磁盘读取一页的开销 = 寻道时间 + 旋转延迟 + 传输时间
2

3
# 假设 HDD 参数：
4
# 寻道时间：5ms
5
# 旋转延迟：4ms (7200 RPM)
6
# 传输速率：100MB/s
7

8
# 读取 4KB：5 + 4 + 0.04 = 9.04ms（传输只占 0.4%）
9
# 读取 64KB：5 + 4 + 0.64 = 9.64ms（传输只占 6.6%）
10
# 读取 1MB：5 + 4 + 10 = 19ms（传输占 52%）
11

12
# 页面越大，每次 I/O 传输的数据越多，利用率越高
13
# 但也意味着读入更多不需要的数据（预读浪费）

1
# 查看 ext4 文件系统的块大小
2
sudo tune2fs -l /dev/sda1 | grep "Block size"
3
# 输出：Block size: 4096
4

5
# ext4 默认块大小也是 4KB
6
# 这与页大小对齐，使得一个文件系统块恰好对应一个内存页
7
# 大大简化了页面缓存的实现

1
虚拟地址（48 位有效）：
2
┌─────┬─────┬─────┬─────┬──────────┐
3
│ PML4│ PDPT│ PD  │ PT  │ Offset   │
4
│9位  │9位  │9位  │9位  │12位      │
5
└─────┴─────┴─────┴─────┴──────────┘
6
  每级 512 项          页内偏移
7

8
4KB 页 + 四级页表：
9
- 每个页表占 4KB（512 项 × 8 字节/项）
10
- 每个页表恰好一页，管理方便

1
# 检查是否支持 5 级页表
2
# Linux 4.14+ 支持
3
cat /proc/cpuinfo | grep la57
4

5
# 5 级页表虚拟地址空间：
6
# 48 位：256 TB
7
# 57 位：128 PB
8
# 对大内存服务器（TB 级）非常有意义

1
// C 程序获取页大小
2
#include <unistd.h>
3
#include <stdio.h>
4

5
int main() {
6
    long page_size = sysconf(_SC_PAGESIZE);
7
    printf("Page size: %ld bytes\n", page_size);
8
    // 输出：Page size: 4096 bytes
9
    return 0;
10
}

1
# Shell 中查看页大小
2
getconf PAGESIZE
3
# 输出：4096
4

5
# 或者
6
cat /proc/sys/vm/page_size  # 某些系统
7
# 或者
8
pagesize

1
4KB 页：
2
- 需要的 TLB 项：10GB / 4KB = 2,621,440 项
3
- L2 STLB 容量：~1536 项
4
- TLB 命中率：极低
5

6
2MB 大页：
7
- 需要的 TLB 项：10GB / 2MB = 5120 项
8
- L2 STLB 容量：~1536 项
9
- TLB 命中率：仍然不足，但好很多
10

11
1GB 大页：
12
- 需要的 TLB 项：10GB / 1GB = 10 项
13
- L2 STLB 容量：~1536 项
14
- TLB 命中率：接近 100%

1
# 查看 HugePages 配置
2
cat /proc/meminfo | grep -i huge
3
# HugePages_Total:     0
4
# HugePages_Free:      0
5
# Hugepagesize:     2048 kB
6

7
# 预分配 HugePages（需要 root）
8
echo 1024 > /proc/sys/vm/nr_hugepages
9
# 分配 1024 个 2MB 大页 = 2GB 大页内存
10

11
# 在程序中使用 HugePages
12
# 方法 1：shmget with SHM_HUGETLB
13
# 方法 2：mmap with MAP_HUGETLB
14
# 方法 3：mount hugetlbfs 文件系统

1
# 查看透明大页状态
2
cat /sys/kernel/mm/transparent_hugepage/enabled
3
# [always] madvise never
4

5
# always：内核自动尝试使用大页
6
# madvise：只在应用通过 madvise(MADV_HUGEPAGE) 请求时使用
7
# never：禁用透明大页
8

9
# 查看 THP 使用情况
10
cat /sys/kernel/mm/transparent_hugepage/defrag

1
# PostgreSQL 推荐配置 HugePages
2
# postgresql.conf:
3
# huge_pages = try  # 尝试使用 HugePages
4

5
# 计算需要的 HugePages 数量
6
# shared_buffers = 4GB
7
# 4GB / 2MB = 2048 个 HugePages
8

9
# 需要预留一些额外页给其他共享内存
10
echo 2300 > /proc/sys/vm/nr_hugepages
11

12
# Redis 使用 HugePages 的注意事项
13
# Redis 官方建议：如果不使用 THP，可以直接使用静态 HugePages
14
# 但 THP 可能导致 fork 延迟（Copy-on-Write 时大页的复制代价高）

1
# macOS (Apple Silicon) 上的页大小
2
pagesize
3
# 输出：16384（16KB）
4

5
# Linux arm64 可以在编译时选择页大小
6
# CONFIG_ARM64_PAGE_SHIFT=12 → 4KB
7
# CONFIG_ARM64_PAGE_SHIFT=14 → 16KB
8
# CONFIG_ARM64_PAGE_SHIFT=16 → 64KB
9

10
# 16KB 页的优势：
11
# - TLB 覆盖范围扩大 4 倍
12
# - 页表项数减少 4 倍
13
# - 更好的压缩率（更多对象可放入同一页）
14

15
# 16KB 页的劣势：
16
# - 内部碎片增加
17
# - 与 x86 生态的默认配置不兼容

1
4KB 页 COW：
2
- 修改 1 字节只需要复制 4KB 页面
3
- Redis fork 子进程做 RDB 快照时，内存开销小
4

5
2MB 大页 COW：
6
- 修改 1 字节需要复制 2MB 页面
7
- 如果大量页面被修改，内存暴增
8
- 这就是 Redis 在使用 THP 时延迟飙升的原因

1
# Redis 官方建议禁用 THP
2
echo never > /sys/kernel/mm/transparent_hugepage/enabled
3

4
# 原因：Redis 使用 fork + COW 做持久化
5
# THP 导致 COW 时复制 2MB 而非 4KB
6
# 在写入密集场景下，内存使用量可能翻倍

1
// mmap 的偏移必须是页大小的整数倍
2
#include <sys/mman.h>
3
#include <fcntl.h>
4

5
int fd = open("large_file.dat", O_RDONLY);
6

7
// 正确：偏移 4096 = 1 × 4KB
8
char *p1 = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, 4096);
9

10
// 错误：偏移 1000 不是页对齐的
11
// char *p2 = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, 1000);
12
// 报错：EINVAL