内存注册与MR管理：错误的内存注册方式、内存钉扎（Pinning）导致的性能问题、MR泄漏与生命周期管理
内存注册（Memory Registration）是RDMA编程里最基础、也最容易踩坑的环节。我见过太多人，上来就写代码，结果性能上不去，甚至直接报错，最后发现都是MR（Memory Region）惹的祸。今天咱们就把这块掰开揉碎了讲清楚。
一、错误的内存注册方式
先说说最常见的错误——注册了不该注册的内存。RDMA要求内存必须是“注册”过的，说白了就是告诉网卡：这块内存你可以直接访问。但很多人不知道，注册内存是有代价的。
为什么？栈内存的生命周期太短了。函数一返回，栈帧就没了。但网卡可能还在用这个地址做DMA操作。结果就是——数据损坏，或者直接segfault。
我在项目中遇到过一个小伙子，他图省事，直接在栈上分配了一个buffer，然后注册成MR。测试时跑得挺好，一上生产就随机崩溃。查了两天，最后发现是栈内存被回收了，但网卡还在写数据。嗯，这种bug最难查。
正确的做法是什么？用堆内存，或者用mmap分配的大页内存。而且注册前要确保内存对齐——通常要求4K对齐，有些网卡甚至要求2M对齐。
// 错误示例：注册栈内存
void bad_example() {
char buf[1024]; // 栈内存
struct ibv_mr *mr = ibv_reg_mr(pd, buf, sizeof(buf),
IBV_ACCESS_LOCAL_WRITE);
// 函数返回后，buf被回收，但mr还在用
}
// 正确示例：注册堆内存
void good_example() {
char *buf = malloc(1024);
struct ibv_mr *mr = ibv_reg_mr(pd, buf, 1024,
IBV_ACCESS_LOCAL_WRITE);
// 记得在不再使用时 deregister 并 free
}
还有一个坑——注册了太大的内存区域。你想想看，注册一个1GB的MR，网卡内部要建立映射表，这本身就有开销。我建议按需注册，别贪大。
二、内存钉扎（Pinning）导致的性能问题
内存钉扎，说白了就是把物理内存锁住，不让操作系统换出到磁盘。RDMA必须这么做，因为网卡直接访问物理地址，不能容忍page fault。
但问题来了——钉扎内存会影响操作系统的内存管理。你钉扎得越多，系统可用的可换出内存就越少。严重时会导致系统OOM（Out Of Memory）。
我记得有个项目，团队为了追求极致性能，一次性注册了所有可用内存的80%。结果呢？其他进程开始频繁swap，整体吞吐量反而下降了。这就是典型的“局部最优，全局不优”。
怎么解决？我个人的习惯是：
- 控制钉扎总量：不要超过物理内存的50%，留出余量给系统和其他进程
- 使用动态注册：用多少注册多少，用完就解注册
- 考虑大页：2M或1G的大页可以减少页表项数量，降低TLB miss
| 内存类型 | 页大小 | 注册开销 | TLB效率 | 适用场景 |
|---|---|---|---|---|
| 普通页 | 4K | 高 | 低 | 小数据量 |
| 大页 | 2M | 中 | 高 | 大数据量 |
| 巨页 | 1G | 低 | 极高 | 超大内存场景 |
还有一个容易被忽略的点——钉扎内存的释放时机。如果你在程序退出前没有解注册，操作系统会帮你清理。但如果你在运行中频繁注册/解注册，内存碎片会越来越严重。
三、MR泄漏与生命周期管理
MR泄漏，说白了就是注册了内存但忘了解注册。这和内存泄漏一样可怕，甚至更隐蔽——因为MR不仅占用内存，还占用网卡硬件资源。
为什么会泄漏？最常见的原因是异常路径没处理好。比如程序收到信号退出，或者某个函数提前return了，但解注册的代码没执行到。
// 简单的RAII封装示例
class RdmaMr {
public:
RdmaMr(struct ibv_pd *pd, void *addr, size_t length, int access) {
mr_ = ibv_reg_mr(pd, addr, length, access);
if (!mr_) {
throw std::runtime_error("ibv_reg_mr failed");
}
}
~RdmaMr() {
if (mr_) {
ibv_dereg_mr(mr_);
mr_ = nullptr;
}
}
// 禁止拷贝，允许移动
RdmaMr(const RdmaMr&) = delete;
RdmaMr& operator=(const RdmaMr&) = delete;
struct ibv_mr* get() const { return mr_; }
private:
struct ibv_mr *mr_ = nullptr;
};
我曾经接手过一个项目，生产环境跑了半年，突然报“无法注册新的MR”。查了半天，发现是某个worker线程在处理完请求后，忘了调用ibv_dereg_mr。日积月累，网卡的MR表项用完了。
MR的生命周期管理，核心就三点：
- 谁注册，谁解注册：不要跨模块传递MR的所有权，除非你很清楚生命周期
- 异常路径要覆盖：每个return、每个异常捕获处，都要检查是否需要解注册
- 监控MR数量：在调试模式下，定期打印当前活跃的MR数量，发现异常增长及时排查
最后说一句，MR管理没有银弹。每个场景都有自己的特点。但只要你记住“注册有代价、钉扎要节制、泄漏要防范”这三点，大部分坑都能避开。