Re: [RFC PATCH 1/2] mm: make lazy MMU mode context-aware

[Alexander Gordeev <agordeev@linux.ibm.com>]

On Mon, Apr 13, 2026 at 08:32:11PM +0200, David Hildenbrand (Arm) wrote:
> > 1. copy_pte_range() operates on two ranges: source and destination.
> > Though lazy_mmu_mode_enable_for_pte_range() applies to the source one,
> > updates to the destination are still happen while in tha lazy mode.
> > (Although the lazy mode is not actually needed for the destination
> > unattached MM).
> 
> So, here a
> 
>   "No ptes outside of this range in the provided @mm must be updated."
> 
> could be used.
> 
> > 
> > 2. move_ptes() also operates on a source and destination ranges, but
> > unlike copy_pte_range() the destination range is also attached to the
> > currently active task.
> 
> But not here.

I did not quite understand these two comments ;), but I think
I address them further below.

> > 3. Though theoretical, nesting sections with interleaving calls to
> > lazy_mmu_mode_enable() and lazy_mmu_mode_enable_for_pte_range() make
> > it difficult to define (let alone to implement) which range is currently
> > active, if any.
> 
> Right. I assume you would specify the source here as well, or which one
> would it be in your case to speed it up?

It is in all cases the source/old/existing one.

> > All of these goes away if we switch from for_pte_range() to fast_pte_range()
> > semantics:
> 
> I don't quite like the "fast" in there. I think you can keep the old
> name, but clarifying that it is merely a hint, and only ptes that fall
> into the hint might observe a speedup.

Okay, that simplify things.

> Could performance benefit from multiple ranges? (like in mremap, for
> example)?

No.

> In that case, an explicit hint interface could be reconsidered.

So all things considered, how does it look?

/**                                                                             
 * lazy_mmu_mode_enable_for_pte_range() - Enable the lazy MMU mode with a speedup hint.
 * @mm: Address space the ptes represent.                                       
 * @addr: Address of the first pte.                                             
 * @end: End address of the range.                                              
 * @ptep: Page table pointer for the first entry.                               
 *                                                                              
 * Enters a new lazy MMU mode section; if the mode was not already enabled,         
 * enables it and calls arch_enter_lazy_mmu_mode_for_pte_range().               
 *                                                                              
 * PTEs that fall within the specified range might observe update speedups.         
 * The PTE range must belong to the specified memory space and do not cross         
 * a page table boundary.                                                       
 *                                                                              
 * There are no requirements on the order or range completeness of PTE          
 * updates for the specified range.                                             
 *                                                                              
 * Must be paired with a call to lazy_mmu_mode_disable().                       
 *                                                                                  
 * Has no effect if called:                                                     
 * - While paused - see lazy_mmu_mode_pause()                                   
 * - In interrupt context                                                       
 */                                                                             

> -- 
> Cheers,
> 
> David

Thanks!