On Tue, Aug 18, 2026 at 07:57:06PM +0800, Yanfei Xu wrote: > Hi Peter, Hi, Yanfei,
> > No objection to removing the dead code — it clearly never worked > > I do have one question about the direction, though. The removed logic > was the only in-tree attempt at MR unregistration for the non-pin-all > path. Without it, registered MRs grow monotonically over a migration, > and with large, widely-spread dirty memory over chunks the accumulated > MR metadata (user + kernel) can cost more than pin-all and even perform > worse — which rather defeats the purpose of not pinning everything. > > do we still intend to keep and improve the non-pin-all path going > forward? If so, some form of dynamic MR unregistration will eventually > be needed and it might be worth keeping this code，or at least leaving > a TODO to mark the gap? Thanks for taking a look. This is a valid question to ask. Though it was there for 13 years without being "enhanced", it means the possibility we leverage it in the next couple of years is low. You also discussed the other side of things: I am not a frequent RDMA user, but my understanding is frequent MR reg operations already slow down migration quite a bit. It means dynamic management including unregisters will be even worse. AFAICT, it'll be a challenging task if we want to keep the performance in bar and add a hard throttle to pinned memory. Obviously, RDMA migration users care a bunch on performance. So I see no good reason to not drop it. Even if someone will work out that problem, it's still not much code to add, and it'll likely be easier we design it from scratch with the demand, and without worry of breaking anyone. When that happens (if it ever will..), someone should also send an update to MAINTAINER file on RDMA migration to change it out of Odd Fixes stage.. Thanks, -- Peter Xu
