Re: [PATCH 5/7] mm/migrate: add copy offload registration infrastructure

From: David Rientjes

Date: Sun May 24 2026 - 22:17:08 EST


On Wed, 20 May 2026, Garg, Shivank wrote:

> >> +static bool migrate_offload_do_batch(int reason)
> >> +{
> >> + if (!static_branch_unlikely(&migrate_offload_enabled))
> >> + return false;
> >> +
> >> + switch (reason) {
> >> + case MR_COMPACTION:
> >> + case MR_SYSCALL:
> >> + case MR_DEMOTION:
> >> + case MR_NUMA_MISPLACED:
> >> + return true;
> >> + default:
> >> + return false;
> >
> >
> > What's the exact reason we don't do this for hotunplug etc? IOW, why do we make
> > this depend on a reason?
>
> Reason-based filtering could be a requirement for some users who want only specific
> use cases to go through DMA offload.
>

+1, I think this makes a lot of sense; not all DMA offloads are created
equally and we may prefer to unburden them from being contended by
migrations that they are not intending to accelerate.

> For the RFC, I introduced a placeholder to enable further discussion on which use cases
> should allow migration offload and whether offload users actually need this control?
>
> Your other point also makes sense: "If someone migrates a handful of folios, latency is
> likely more important (and batching less beneficial)."
> Based on this, we could either fully rely on batch size. I'll think more about this.
>

There are, or will be, some offloads that must be used for certain types
of page migrations, like Confidential Computing. That's for functional
reasons, not a heuristic.

We want to use certain hardware assists solely for promotion and demotion
of memory for tiering. We certainly wouldn't want those hardware assists
to be inundated by users doing tons of move_pages(2) on their own or by
best effort memory compaction in the kernel.

I think the use cases should be configurable by the user if at all
possible so we can control what has access to being offloaded. These are
often shared system resources and can be contended like any other
resource, so configuring which migrations can use them vs not use them
seems important.