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

[David Rientjes]

Received a bounce for Jonathan, so adding in his other email address.


On Sun, 24 May 2026, David Rientjes wrote:

> 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.
>