On 2026/8/18 21:01, Peter Xu wrote:
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.
One advantage of non-pin-all is that it neither sends the all-zero chunk
nor registers the corresponding MRs. For guests with a low dirty-page
workload and a large number of zero pages, this lets it migrate faster
than pin-all and pin less guest memory during the migration.
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.
Got it, thanks for the explanation.
Regards,
Yanfei
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,
