深入 ‘Persistent Memory’ (PMEM) 编程：内核如何处理像内存一样读写、像磁盘一样持久的存储硬件？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

引言：持久内存的崛起

在计算机存储领域，我们长期以来习惯于一个根深蒂固的层次结构：CPU拥有极快的寄存器和缓存，接着是速度较快但易失的DRAM主内存，再往下是速度相对较慢但持久的NAND闪存（SSD）和硬盘驱动器（HDD）。这个金字塔结构在过去的几十年里支撑了计算世界的飞速发展，但也带来了固有的挑战：性能与持久性之间的巨大鸿沟。DRAM提供字节寻址和纳秒级延迟，但断电即失；SSD提供持久性，但其块寻址特性和微秒甚至毫秒级的延迟，使其无法直接作为主内存使用。

持久内存（Persistent Memory, PMEM），也被称为存储级内存（Storage Class Memory, SCM）或非易失性双列直插内存模块（NVDIMM），正是为了弥合这一鸿沟而诞生的技术。它结合了DRAM的速度（纳秒级延迟）和NAND闪存的非易失性（数据断电不丢失），同时继承了内存的字节寻址能力。这意味着应用程序可以直接在PMEM上操作数据，就像操作DRAM一样，而无需通过传统的块设备I/O栈，并且这些数据在系统重启后依然存在。

PMEM的出现，为操作系统、文件系统以及应用程序的设计带来了范式上的转变。传统上，为了保证数据持久性，应用程序需要将数据从DRAM复制到文件系统管理的缓冲区，再由文件系统写入块设备。这个过程涉及多次数据拷贝、上下文切换和复杂的I/O调度。PMEM则允许应用程序直接将数据“写入”到持久存储中，极大地简化了编程模型，并显著降低了数据持久化的延迟。

那么，作为计算机系统的核心，Linux内核是如何识别、管理并向用户空间暴露这种革命性的存储硬件，使其既能像内存一样被读写，又能像磁盘一样持久化数据呢？这就是我们本次深入探讨的核心。

硬件基础：PMEM的工作模式与内核发现机制

在理解内核如何处理PMEM之前，我们首先需要对PMEM的硬件特性及其工作模式有一个基本的认识。目前市场上主流的PMEM产品包括Intel Optane DC Persistent Memory modules，它们通常以NVDIMM的形式存在。

PMEM硬件通常支持两种主要的工作模式：

Memory Mode (内存模式)：在此模式下，PMEM模块充当DRAM的扩展，但其性能略低于DRAM。系统BIOS会将PMEM配置为DRAM的一部分，并将其作为CPU主内存的下一层缓存或扩展。应用程序和操作系统不会直接感知到PMEM的持久性，它完全像易失性RAM一样工作。通常，DRAM会作为PMEM的写缓存，提供更好的性能。这种模式对于希望拥有更大内存容量，但不需要显式利用PMEM持久性的用户来说非常有用。内核在这种模式下，将其视为普通DRAM来管理。
App Direct Mode (应用直接模式)：这是PMEM发挥其独特持久性特性的关键模式。在此模式下，PMEM不作为DRAM的扩展，而是作为一个独立的内存域，直接暴露给操作系统。操作系统和应用程序可以通过物理地址直接访问这些内存区域，并可以显式地利用其持久性。内核会将这些PMEM区域识别为“NVDIMM”，并提供特定的设备接口供用户空间访问。这种模式是PMEM编程的焦点。

PMEM的内核发现机制

当系统启动时，BIOS/UEFI通过高级配置与电源接口（ACPI）向操作系统报告硬件信息。对于PMEM，相关的ACPI表是NVDIMM固件接口表（NVDIMM Firmware Interface Table, NFIT）。NFIT表包含了系统中所有NVDIMM设备的信息，例如它们的物理地址范围、大小、以及它们如何被组织成“区域”（Regions）和“命名空间”（Namespaces）。

Linux内核在启动时会解析NFIT表，并根据其中的信息识别出App Direct模式下的PMEM设备。内核会将这些物理内存区域抽象为逻辑设备。

ndctl 工具

ndctl是一个用户空间工具，用于管理和配置NVDIMM设备。通过ndctl，系统管理员可以：

列出PMEM模块和它们的物理特性。
创建、配置和删除PMEM命名空间（Namespaces）。
将PMEM区域划分为不同的用途。

一个PMEM“区域”（Region）通常对应一个或多个物理NVDIMM模块。一个区域可以进一步被划分为一个或多个“命名空间”（Namespace）。命名空间是内核向用户空间暴露PMEM设备的基本单元。它们可以是：

fsdax (File System DAX) 命名空间：这种命名空间可以在其上创建文件系统（如ext4或XFS），并以DAX（Direct Access）模式挂载。DAX允许文件数据直接映射到用户空间，绕过页缓存。
devdax (Device DAX) 命名空间：这种命名空间直接暴露为字符设备（/dev/daxX.Y），允许应用程序直接mmap到整个持久内存区域，而无需文件系统介入。
sector 命名空间：将PMEM暴露为传统的块设备（/dev/pmemX），可以在其上创建传统文件系统，但无法利用DAX的优势。

以下是使用ndctl列出PMEM设备和创建命名空间的示例：

# 列出所有PMEM区域
$ sudo ndctl list --regions

# 示例输出：
# [
#   {
#     "dev":"region0",
#     "size":127885062144,
#     "available_size":127885062144,
#     "max_available_extent":127885062144,
#     "type":"pmem",
#     "numa_node":0,
#     "align":2097152,
#     "badblock_count":0,
#     "badblocks":[],
#     "namespaces":[]
#   }
# ]

# 创建一个类型为fsdax的命名空间
# 这里假设region0有足够的空间，并且我们想创建一个128GB的命名空间
$ sudo ndctl create-namespace --region region0 --mode fsdax --size 128G

# 示例输出：
# [
#   {
#     "dev":"namespace0.0",
#     "mode":"fsdax",
#     "map":"dev",
#     "size":128000000000,
#     "uuid":"a1b2c3d4-e5f6-7890-1234-567890abcdef",
#     "raw_uuid":"00000000-0000-0000-0000-000000000000",
#     "blockdev":"pmem0",
#     "state":"active",
#     "numa_node":0
#   }
# ]

# 创建一个类型为devdax的命名空间
# 这里假设region0仍有空间，并创建一个4GB的命名空间
$ sudo ndctl create-namespace --region region0 --mode devdax --size 4G

# 示例输出：
# [
#   {
#     "dev":"dax0.0",
#     "mode":"devdax",
#     "size":4294967296,
#     "uuid":"b1c2d3e4-f5a6-7890-1234-567890abcdef",
#     "raw_uuid":"00000000-0000-0000-0000-000000000000",
#     "align":4096,
#     "blockdev":"pmem1", # 注意：devdax虽然是字符设备，但也会有一个关联的pmem块设备
#     "state":"active",
#     "numa_node":0
#   }
# ]

# 列出所有命名空间
$ sudo ndctl list --namespaces

# 示例输出（可能包含上述创建的两个）：
# [
#   {
#     "dev":"namespace0.0",
#     "mode":"fsdax",
#     "map":"dev",
#     "size":128000000000,
#     "uuid":"a1b2c3d4-e5f6-7890-1234-567890abcdef",
#     "raw_uuid":"00000000-0000-0000-0000-000000000000",
#     "blockdev":"pmem0",
#     "state":"active",
#     "numa_node":0
#   },
#   {
#     "dev":"dax0.0",
#     "mode":"devdax",
#     "size":4294967296,
#     "uuid":"b1c2d3e4-f5a6-7890-1234-567890abcdef",
#     "raw_uuid":"00000000-0000-0000-0000-000000000000",
#     "align":4096,
#     "blockdev":"pmem1",
#     "state":"active",
#     "numa_node":0
#   }
# ]

内核对PMEM的抽象与暴露：从块设备到直接访问

Linux内核通过不同的接口将PMEM暴露给用户空间，以适应不同的应用场景和性能需求。理解这些接口的差异是进行PMEM编程的关键。

1. 块设备接口：熟悉但有局限

最简单也是最传统的方式是将PMEM作为普通的块设备来使用。当PMEM命名空间被配置为sector模式（或fsdax模式创建后，底层依然有一个pmemX块设备），内核会为其创建一个块设备节点，通常是/dev/pmemX（例如/dev/pmem0）。

使用方式：
- 可以在/dev/pmemX上创建传统的文件系统，如ext4、XFS或btrfs。
- 通过mkfs命令格式化设备。
- 通过mount命令挂载文件系统。
- 应用程序可以使用标准的文件I/O接口（open, read, write, close）来操作文件。

代码示例：将PMEM作为块设备使用

# 假设我们有一个名为/dev/pmem0的PMEM块设备
# 1. 格式化为ext4文件系统
sudo mkfs.ext4 /dev/pmem0

# 2. 创建一个挂载点
sudo mkdir /mnt/pmem_blk

# 3. 挂载文件系统
sudo mount /dev/pmem0 /mnt/pmem_blk

# 4. 像操作普通文件系统一样使用
echo "Hello Persistent Memory!" > /mnt/pmem_blk/test_file.txt
cat /mnt/pmem_blk/test_file.txt

# 5. 卸载文件系统
sudo umount /mnt/pmem_blk

# 6. 删除挂载点
sudo rmdir /mnt/pmem_blk

优缺点分析：

特性	优点	缺点
优点	编程模型熟悉，现有工具和文件系统可直接使用	无法充分发挥PMEM的字节寻址能力
	兼容性好，无需特殊应用修改	数据通过页缓存（page cache）进行读写，引入了额外的拷贝和延迟
	操作系统负责数据一致性和持久性	文件系统元数据更新、日志等操作会引入额外开销
		性能上与SSD相比提升有限，不适合低延迟、字节粒度的操作

这种方式虽然简单易用，但它将PMEM降级为另一种“快一点的磁盘”，完全失去了PMEM字节寻址和内存语义的独特优势。数据仍然需要经过操作系统页缓存、文件系统层层处理，才能最终落到PMEM上。

2. DAX (Direct Access) 接口：绕过页缓存的革新

为了充分利用PMEM的字节寻址能力和低延迟特性，Linux内核引入了DAX（Direct Access）机制。DAX允许应用程序直接将文件数据映射到用户空间的虚拟地址空间，而无需经过内核的页缓存。这意味着，当应用程序读写映射的内存区域时，数据直接从PMEM设备读写，避免了传统文件I/O的数据拷贝和页缓存管理开销。

使用方式：
- PMEM命名空间必须是fsdax模式。
- 在/dev/pmemX设备上创建DAX支持的文件系统（ext4或XFS）。
- 在挂载文件系统时，需要指定dax挂载选项。
- 应用程序使用mmap()系统调用将文件内容映射到进程的虚拟地址空间。
- 读写映射区域等同于直接读写PMEM。
- 使用msync()或fsync()保证数据持久性。

代码示例：使用DAX mmap访问PMEM文件

假设我们已经将/dev/pmem0格式化为ext4并以dax模式挂载到/mnt/pmem_dax。

# 假设/dev/pmem0已经格式化并挂载到/mnt/pmem_dax
# sudo mkfs.ext4 -F /dev/pmem0
# sudo mount -o dax /dev/pmem0 /mnt/pmem_dax

dax_pmem_example.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <errno.h>

#define PMEM_FILE_PATH "/mnt/pmem_dax/my_persistent_data"
#define DATA_SIZE (4 * 1024 * 1024) // 4MB

int main() {
    int fd;
    char *pmem_addr;
    const char *test_string = "Hello from Persistent Memory via DAX mmap!";
    size_t test_string_len = strlen(test_string);

    // 1. 打开或创建文件
    // O_CREAT: 如果文件不存在则创建
    // O_RDWR: 读写模式
    // S_IRUSR | S_IWUSR: 读写权限
    fd = open(PMEM_FILE_PATH, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
    if (fd < 0) {
        perror("Error opening/creating file");
        return 1;
    }

    // 2. 确保文件大小足够，以便mmap能够映射整个区域
    if (ftruncate(fd, DATA_SIZE) < 0) {
        perror("Error truncating file");
        close(fd);
        return 1;
    }

    // 3. 将文件映射到进程的虚拟地址空间
    // NULL: 让系统选择映射地址
    // DATA_SIZE: 映射的长度
    // PROT_READ | PROT_WRITE: 读写权限
    // MAP_SHARED: 共享映射，对内存的修改会反映到文件中（持久化）
    // fd: 文件描述符
    // 0: 映射的起始偏移量
    pmem_addr = mmap(NULL, DATA_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (pmem_addr == MAP_FAILED) {
        perror("Error mmapping file");
        close(fd);
        return 1;
    }

    // 4. 写入数据到映射区域
    // 直接像操作内存一样写入
    strncpy(pmem_addr, test_string, DATA_SIZE - 1);
    pmem_addr[DATA_SIZE - 1] = ''; // 确保字符串以null结尾

    printf("Data written to PMEM: %sn", pmem_addr);

    // 5. 确保数据持久化
    // msync() 将修改的数据从CPU缓存刷新到持久内存
    // MS_SYNC: 同步刷新，等待操作完成
    if (msync(pmem_addr, DATA_SIZE, MS_SYNC) < 0) {
        perror("Error msyncing data");
        // 即使msync失败，数据可能仍在CPU缓存或PMEM中，但持久性无法保证
        // 依赖硬件和OS的实现，某些情况下可能自动刷新
    }

    printf("Data synced to PMEM.n");

    // 6. 关闭文件描述符，不影响映射的内存区域
    close(fd);

    // 7. 解除内存映射
    if (munmap(pmem_addr, DATA_SIZE) < 0) {
        perror("Error unmapping memory");
        return 1;
    }

    printf("Memory unmapped. Re-opening file to verify persistence...n");

    // 8. 重新打开文件并映射，验证数据是否持久化
    fd = open(PMEM_FILE_PATH, O_RDWR);
    if (fd < 0) {
        perror("Error re-opening file");
        return 1;
    }

    pmem_addr = mmap(NULL, DATA_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (pmem_addr == MAP_FAILED) {
        perror("Error re-mmapping file");
        close(fd);
        return 1;
    }

    printf("Data read from PMEM (after re-open): %sn", pmem_addr);

    // 9. 清理
    munmap(pmem_addr, DATA_SIZE);
    close(fd);
    unlink(PMEM_FILE_PATH); // 删除文件

    return 0;
}

编译并运行：

gcc -o dax_pmem_example dax_pmem_example.c
./dax_pmem_example

优缺点分析：

特性	优点	缺点
优点	字节寻址，应用程序直接操作PMEM	仍然需要文件系统管理元数据（目录、文件名、权限等），存在一定开销
	绕过页缓存，避免数据拷贝，降低延迟	需要文件系统支持DAX（ext4, XFS），且需要显式挂载选项
	编程模型与传统内存映射文件相似，易于理解	数据持久性仍需应用程序显式通过`msync()`或`fsync()`保证
	利用了文件系统的管理能力，简化了数据管理	对于需要极致性能或完全自定义数据布局的应用，仍有额外开销

DAX模式是目前PMEM编程的主流方式，它在利用PMEM性能的同时，保留了文件系统的便利性。

3. 裸设备DAX (Raw DAX) 接口：极致的控制与性能

对于那些需要最高性能、最低延迟，并且愿意自行管理数据结构和持久性语义的应用程序，内核提供了裸设备DAX接口。当PMEM命名空间被配置为devdax模式时，内核会为其创建一个字符设备节点，通常是/dev/daxX.Y（例如/dev/dax0.0）。

使用方式：
- PMEM命名空间必须是devdax模式。
- 应用程序直接打开/dev/daxX.Y设备。
- 使用mmap()系统调用将整个设备映射到进程的虚拟地址空间。
- 应用程序完全负责持久内存区域内的数据布局、一致性、原子性以及错误恢复。
- 通常配合像PMDK（Persistent Memory Development Kit）这样的库来简化开发。

代码示例：使用裸设备DAX mmap访问PMEM

假设我们有一个名为/dev/dax0.0的裸设备DAX设备。

raw_dax_pmem_example.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <errno.h>

#define DAX_DEVICE_PATH "/dev/dax0.0"
#define DAX_SIZE (4 * 1024 * 1024) // 4MB，确保小于DAX设备的实际大小

int main() {
    int fd;
    char *pmem_addr;
    const char *test_string = "Hello from Persistent Memory via Raw DAX!";
    size_t test_string_len = strlen(test_string);

    // 1. 打开DAX设备
    // O_RDWR: 读写模式
    fd = open(DAX_DEVICE_PATH, O_RDWR);
    if (fd < 0) {
        perror("Error opening DAX device");
        // 通常是权限问题，或设备不存在/大小不足
        fprintf(stderr, "Please ensure %s exists and is accessible. "
                        "You might need to create it with 'sudo ndctl create-namespace --region regionX --mode devdax --size YGB'n",
                        DAX_DEVICE_PATH);
        return 1;
    }

    // 2. 将整个DAX设备映射到进程的虚拟地址空间
    // NULL: 让系统选择映射地址
    // DAX_SIZE: 映射的长度 (确保小于或等于实际的DAX设备大小)
    // PROT_READ | PROT_WRITE: 读写权限
    // MAP_SHARED: 共享映射，对内存的修改会反映到持久内存
    // fd: 文件描述符
    // 0: 映射的起始偏移量
    pmem_addr = mmap(NULL, DAX_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (pmem_addr == MAP_FAILED) {
        perror("Error mmapping DAX device");
        close(fd);
        return 1;
    }

    // 3. 写入数据到映射区域
    strncpy(pmem_addr, test_string, DAX_SIZE - 1);
    pmem_addr[DAX_SIZE - 1] = ''; // 确保字符串以null结尾

    printf("Data written to PMEM: %sn", pmem_addr);

    // 4. 确保数据持久化
    // 对于裸DAX，msync()是确保数据从CPU缓存刷新到持久内存的关键
    if (msync(pmem_addr, DAX_SIZE, MS_SYNC) < 0) {
        perror("Error msyncing data");
    }
    printf("Data synced to PMEM.n");

    // 5. 关闭文件描述符，不影响映射的内存区域
    close(fd);

    // 6. 解除内存映射
    if (munmap(pmem_addr, DAX_SIZE) < 0) {
        perror("Error unmapping memory");
        return 1;
    }

    printf("Memory unmapped. Re-opening DAX device to verify persistence...n");

    // 7. 重新打开设备并映射，验证数据是否持久化
    fd = open(DAX_DEVICE_PATH, O_RDWR);
    if (fd < 0) {
        perror("Error re-opening DAX device");
        return 1;
    }

    pmem_addr = mmap(NULL, DAX_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (pmem_addr == MAP_FAILED) {
        perror("Error re-mmapping DAX device");
        close(fd);
        return 1;
    }

    printf("Data read from PMEM (after re-open): %sn", pmem_addr);

    // 8. 清理
    munmap(pmem_addr, DAX_SIZE);
    close(fd);

    return 0;
}

编译并运行：

gcc -o raw_dax_pmem_example raw_dax_pmem_example.c
./raw_dax_pmem_example

优缺点分析：

特性	优点	缺点
优点	极致的性能和最低的延迟，完全绕过文件系统开销	编程模型复杂，应用程序需要自行管理数据结构、内存布局、并发控制、原子性、错误恢复等
	应用程序对持久内存拥有完全的控制权	缺乏文件系统的抽象和便利性（如目录、文件权限、命名等）
	最适合需要高度定制化数据布局和并发控制的系统级应用	通常需要借助PMDK等专业库来降低开发复杂性
		无法直接使用标准的文件系统工具和命令

接口对比总结表格

特性/接口	块设备（`/dev/pmemX`）	DAX文件系统（`/mnt/pmem_dax`）	裸设备DAX（`/dev/daxX.Y`）
底层设备	`sector`或`fsdax`命名空间关联的`pmem`块设备	`fsdax`命名空间关联的`pmem`块设备	`devdax`命名空间关联的`dax`字符设备
文件系统	必需，传统文件系统（ext4, XFS）	必需，DAX支持的文件系统（ext4, XFS），需`dax`挂载选项	无文件系统
数据路径	经页缓存 -> 文件系统 -> 块设备	直接映射（`mmap`），绕过页缓存，文件系统管理元数据	直接映射（`mmap`），完全绕过文件系统和页缓存
寻址粒度	块（通常4KB）	字节	字节
编程模型	传统文件I/O (`read`, `write`)	内存映射文件 (`mmap`)，像操作内存一样读写	内存映射设备 (`mmap`)，像操作内存一样读写
持久化	`fsync()`, `fdatasync()`	`msync(MS_SYNC)`, `fsync()`	`msync(MS_SYNC)`
性能	最低	较高，低延迟	最高，最低延迟
复杂性	最低	中等	最高，需自行管理一切
适用场景	传统应用，对PMEM性能要求不高的场景	大多数需要高性能和持久性的应用，如数据库日志、索引等	对性能极致要求，愿意自行管理底层细节的系统级应用

持久性保证与数据一致性：跨越CPU与存储边界

PMEM的核心挑战之一是如何确保数据真正地从CPU易失性缓存刷新到PMEM的持久化存储域，并保证操作的原子性和一致性，即使在系统崩溃或断电的情况下。

1. CPU缓存与持久性边界

当CPU执行写操作时，数据首先被写入CPU的L1、L2、L3缓存。这些缓存是易失的。只有当数据从CPU缓存被“刷新”（flush）到主内存（这里是PMEM）时，它才真正变得持久。如果系统在数据仍在CPU缓存中时崩溃，这些数据就会丢失。

为了解决这个问题，Intel x86-64架构提供了特殊的CPU指令：

clflushopt (Cache Line Flush Optimized)：将指定地址所在的整个缓存行从CPU缓存中刷新到下一级内存层次结构，直到持久内存。它是clflush的优化版本，可以乱序执行，通常更快。
clwb (Cache Line Write Back)：将指定地址所在的缓存行写回内存，但并不作废缓存行。这意味着缓存行仍然可以被CPU访问，从而避免了clflushopt导致的缓存缺失。这是PMEM编程中更推荐使用的刷新指令，因为它能更好地保持缓存性能。
sfence (Store Fence)：内存屏障指令，确保在sfence指令之后的所有存储操作在sfence之前的存储操作都完成后才开始执行。这对于保证数据写入的顺序性至关重要。

这些指令通常由内核或专门的PMEM库（如PMDK）在底层调用。应用程序一般不需要直接使用它们。

msync() 系统调用：
- 在DAX文件系统或裸DAX设备上，mmap映射的内存区域中的数据，需要通过msync()系统调用来强制刷新。
- msync(addr, len, MS_SYNC)：将addr开始的len字节范围内的所有修改，从CPU缓存同步刷新到PMEM。它会阻塞直到刷新完成。
- msync(addr, len, MS_ASYNC)：异步刷新，不阻塞。
- msync()在底层会根据需要调用clflushopt或clwb和sfence来保证数据持久性。
fsync() 系统调用：
- 对于DAX文件系统，fsync(fd)用于将文件数据和元数据从内核的页缓存（如果存在）和文件系统内部缓冲区刷新到PMEM。
- 即使在DAX模式下，文件系统元数据（如文件大小、修改时间、目录结构等）仍然会经过内核的文件系统层。fsync()确保这些元数据的持久性。

2. 原子性与数据撕裂（Tearing）

PMEM的字节寻址能力带来了一个新的问题：数据撕裂（Tearing）。如果一个多字节的数据结构（如一个struct或一个long变量）在写入过程中发生断电，可能只有部分字节被写入PMEM，导致数据处于不一致状态。

硬件原子性：在x86-64架构上，单个8字节（64位）的写入操作通常是原子性的。这意味着，即使在断电时，一个8字节的写入要么完全发生，要么完全不发生，不会出现部分写入的情况。
软件原子性：对于大于8字节的数据结构或复杂的多个数据结构更新，需要通过软件机制来保证原子性。这通常涉及到事务处理、日志（Journaling）或写时复制（Copy-on-Write）等技术。

3. PMDK (Persistent Memory Development Kit) 深度解析

为了简化PMEM编程的复杂性，Intel开发了Persistent Memory Development Kit (PMDK)。PMDK是一套开源库，旨在提供高层次的抽象，帮助开发者构建可靠、高性能的持久化应用程序。它在底层处理了clflushopt/clwb/sfence指令、内存屏障、原子性保证以及复杂的持久化数据结构管理。

PMDK包含多个库，其中最核心的是：

libpmemobj：提供一个事务性对象存储模型。它允许开发者创建持久化内存池，并在其中分配持久化对象。libpmemobj提供了事务机制，确保对持久化数据的复杂修改能够原子地完成，即使在系统崩溃的情况下也能恢复到一致状态。它还包括持久化内存分配器和各种持久化数据结构（如pmem::obj::vector, pmem::obj::map等）。
libpmem：提供低级别的持久化内存管理功能，如内存池的创建、映射、刷新操作。它封装了msync和CPU缓存刷新指令，提供更简洁的API。
libpmemlog：用于实现持久化日志文件。
libvmmalloc：一个特殊的malloc实现，可以将应用程序的堆分配重定向到PMEM。

代码示例：使用libpmemobj创建持久化池和事务

这个示例演示了如何使用libpmemobj创建一个持久化内存池，并在其中存储一个字符串，通过事务保证原子性。

pmemobj_example.c:

#include <libpmemobj.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

// 定义一个持久化根对象类型
// PMEM_MAX_TYPE_NUM 是 libpmemobj 定义的最大类型号
// 这里我们简单使用一个固定的类型号
#define LAYOUT_NAME "my_app_layout"

// 定义一个持久化结构体，作为内存池的根对象
// POBJ_ROOT() 宏用于声明根对象
struct my_root {
    char message[PMEMOBJ_MAX_ALLOC_SIZE]; // 存储一个消息
};

int main(int argc, char *argv[]) {
    PMEMobjpool *pop = NULL;
    PMEMoid root_oid; // 持久化对象的OID (Object ID)
    struct my_root *root = NULL;
    const char *path = "/mnt/pmem_dax/my_pmem_pool"; // 持久化内存池文件路径
    const char *new_message = "New message written persistently!";

    // 1. 打开或创建持久化内存池
    // pmemobj_open: 打开一个已存在的池
    // pmemobj_create: 创建一个新的池
    pop = pmemobj_open(path, LAYOUT_NAME);

    if (pop == NULL) {
        // 如果文件不存在或打开失败，尝试创建
        // 1024 * 1024 * 1024: 1GB 池大小
        pop = pmemobj_create(path, LAYOUT_NAME, 1024 * 1024 * 1024, 0666);
        if (pop == NULL) {
            perror("Failed to create or open pmemobj pool");
            return 1;
        }
        printf("Created new pmemobj pool at %sn", path);
    } else {
        printf("Opened existing pmemobj pool at %sn", path);
    }

    // 2. 获取内存池的根对象
    // 根对象是内存池中第一个被分配的持久化对象，用于存储其他对象的引用
    root_oid = pmemobj_root(pop, sizeof(struct my_root));
    if (OID_IS_NULL(root_oid)) {
        perror("Failed to get root object");
        pmemobj_close(pop);
        return 1;
    }

    // 将OID转换为可直接访问的指针
    root = (struct my_root *)pmemobj_direct(root_oid);

    // 3. 读取当前消息
    printf("Current message in PMEM: %sn", root->message);

    // 4. 使用事务更新消息
    // POBJ_TX_BEGIN() 宏启动一个事务
    // POBJ_TX_END() 宏提交事务
    // 事务保证了在崩溃恢复后，数据要么是旧值，要么是新值，不会出现中间状态
    TX_BEGIN(pop) {
        // POBJ_TX_ADD() 将对象添加到事务中，以便在回滚时恢复其原始状态
        // 每次事务修改一个持久化对象时，都需要将其添加到事务中
        // 对于根对象，通常只需要添加一次
        POBJ_TX_ADD(root_oid);

        // 修改数据
        strncpy(root->message, new_message, sizeof(root->message) - 1);
        root->message[sizeof(root->message) - 1] = ''; // 确保null终止
        printf("Inside transaction: message changed to '%s'n", root->message);

        // 如果在事务中发生错误或崩溃，所有修改都会被回滚
        // 例如，可以模拟一个错误：
        // if (strcmp(new_message, "Bad message") == 0)
        //     POBJ_TX_ABORT(EINVAL); // 强制事务回滚
    } TX_ONABORT {
        fprintf(stderr, "Transaction aborted: %sn", pmemobj_errormsg());
    } TX_END // 提交事务

    // 5. 再次读取消息，验证事务是否成功
    printf("Message after transaction: %sn", root->message);

    // 6. 关闭内存池
    pmemobj_close(pop);

    // 为了演示持久性，可以删除文件并在下次运行时重新创建
    // remove(path);

    return 0;
}

编译并运行：

# 确保安装了libpmemobj-dev包 (或pmdk-devel)
# 例如在Ubuntu/Debian: sudo apt install libpmemobj-dev
# 在CentOS/Fedora: sudo dnf install pmdk-devel

gcc -o pmemobj_example pmemobj_example.c -lpmemobj
./pmemobj_example

第一次运行会创建池并写入消息。再次运行，会打开已存在的池并显示上次写入的消息。如果程序在TX_END之前崩溃，下次运行会发现消息仍然是旧的（即事务回滚），保证了原子性。

PMDK极大地简化了PMEM编程的复杂性，提供了高级抽象和工具来处理底层细节，是开发可靠PMEM应用程序的首选方式。

PMEM编程的挑战与最佳实践

尽管PMEM带来了巨大的潜力，但在实际编程中，开发者仍然需要面对一些独特的挑战。

1. 持久化指针与数据结构设计

传统C/C++程序中的指针是针对易失性DRAM设计的，其地址在每次程序启动时都可能不同。但在PMEM中，数据是持久的，这意味着如果一个结构体存储了一个指向另一个持久化对象的指针，这个指针在系统重启后可能不再有效（因为进程的虚拟地址空间布局可能改变）。

最佳实践：

使用偏移量（Offsets）而非绝对指针：将指针存储为相对于持久化区域基地址的偏移量。当程序启动并映射PMEM时，可以根据基地址和偏移量计算出实际的运行时指针。PMDK的libpmemobj库通过PMEMoid（持久化对象ID）抽象了这一概念，PMEMoid本质上就是池ID和偏移量的组合。
避免在持久化数据结构中直接存储堆分配的指针：如果必须引用易失性堆内存，确保在程序退出前将其内容刷新到PMEM，并在下次启动时重新加载。
数据结构对齐：为了获得最佳性能，确保数据结构成员是缓存行对齐的（通常是64字节）。

2. 内存管理与分配器

标准库的malloc()和free()是为易失性DRAM设计的，它们无法管理PMEM，也无法保证分配的持久性。

最佳实践：

使用PMDK提供的持久化内存分配器：libpmemobj提供了自己的分配器（pmemobj_alloc, pmemobj_free），它们在持久化内存池中进行分配和回收，并能保证在崩溃恢复后的内存一致性。
libvmmalloc：如果希望将现有应用程序的malloc/free调用透明地重定向到PMEM，可以使用libvmmalloc。它通过LD_PRELOAD机制拦截标准内存分配函数，将分配重定向到PMEM。但需要注意，这种方式无法提供事务性保障，需要应用程序自行处理数据持久化。

3. 并发控制与锁机制

PMEM是共享资源，多线程或多进程访问时需要适当的并发控制。传统的互斥锁（mutexes）、读写锁（rwlocks）等可以用于保护PMEM中的数据结构，但需要注意锁本身的状态也是易失的。

最佳实践：

持久化锁：PMDK提供了持久化互斥锁（pmem_mutex）和持久化读写锁（pmem_rwlock）。这些锁的状态本身存储在PMEM中，并能在系统崩溃后自动恢复到一致状态（如解锁状态）。
事务的并发性：libpmemobj的事务机制本身提供了某种程度的并发控制，但复杂的并发场景仍需结合持久化锁或原子操作。
原子操作：对于简单的计数器或标志位，可以使用CPU提供的原子指令（如__atomic_add_fetch）直接操作PMEM中的数据，保证原子性。

4. 错误恢复与调试

PMEM编程的一大挑战是调试。数据持久化意味着程序崩溃后，不一致的状态可能依然存在于PMEM中。传统的调试方法可能无法完全捕获这些问题。

最佳实践：

事务性编程：尽可能使用libpmemobj的事务机制，它能自动处理崩溃恢复，将数据恢复到一致状态。
日志和检查点：对于复杂系统，结合使用持久化日志和检查点机制，以便在恢复时回溯操作或加载已知一致的状态。
PMDK工具：PMDK提供了一些调试工具，如pmemobj_check用于检查内存池的完整性。
谨慎对待指针：由于指针可能在重启后失效，仔细检查所有持久化指针的初始化和使用逻辑。

5. 安全性考量

数据在PMEM中是持久的，这意味着敏感数据即使在系统断电后也依然存在。

最佳实践：

数据加密：对于敏感数据，在写入PMEM之前进行加密，并在读取后解密。
安全删除：当数据不再需要时，应确保其被安全擦除，而不仅仅是标记为“空闲”。PMDK提供了一些清除内存的函数。
访问控制：通过文件系统权限（DAX文件）或设备权限（裸DAX）来限制对PMEM的访问。

6. 性能优化

虽然PMEM本身很快，但不当的编程习惯仍可能导致性能瓶颈。

最佳实践：

减少刷新操作：msync()和clwb/sfence是昂贵的操作。尽量批量写入并一次性刷新，而不是每次小更新都刷新。
缓存行对齐：确保数据结构和访问模式与CPU缓存行对齐，减少伪共享（false sharing）和不必要的缓存刷新。
NUMA感知：在多NUMA节点系统中，将PMEM池分配在与访问线程相同的NUMA节点上，以减少跨NUMA访问的延迟。

未来的展望：PMEM与计算存储的融合

PMEM技术仍在快速发展。随着其在数据中心和边缘计算中的普及，我们可以预见以下趋势：

CXL (Compute Express Link) 的影响：CXL是一种开放的行业标准，用于CPU之间、CPU与内存/加速器之间的高速互连。CXL将允许更灵活的内存扩展和共享，使得PMEM可以作为可共享的、异构的内存资源。这意味着未来的系统可能会有多种类型的PMEM，通过CXL连接到多个CPU，从而实现真正的内存池化和计算存储的融合。内核将需要更复杂的CXL管理层来协调这些资源。
内核与文件系统的持续演进：Linux内核将继续优化对PMEM的支持。例如，可能会出现新的文件系统，专门为PMEM的特性而设计，以提供比现有DAX文件系统更低的开销和更高的性能。也可能会有更智能的PMEM管理策略，例如自动识别并刷新热点数据。
更多高级编程模型：PMDK将继续发展，提供更高级别的抽象和更丰富的持久化数据结构，进一步降低PMEM编程的门槛。同时，新的编程语言和运行时环境也可能直接内置对PMEM的支持。

PMEM代表着存储层次结构的重大变革，它为构建高性能、高可靠和持久化的应用程序提供了前所未有的机会。理解其底层机制，掌握内核提供的接口，并利用PMDK等工具，将是每一位现代系统开发者不可或缺的技能。

持久内存的崛起正在重塑我们对存储和内存的传统认知。Linux内核通过从块设备到DAX再到裸设备DAX的多层次抽象，有效地将PMEM的强大功能暴露给用户空间。结合PMDK等工具，开发者可以构建出既能享受内存般速度，又能保证数据持久性的新一代应用程序。

发表回复 取消回复

发表回复取消回复