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

[David Rientjes <rientjes@google.com>]

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.