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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/14/26 09:53, Alexander Gordeev wrote:
> 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.

I'm saying that the second case is the problematic one ;)

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

Make sense.

> 
>>> 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                                                       
>  */                                                                             

LGTM!

-- 
Cheers,

David