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

[David Hildenbrand (Arm)]

On 4/13/26 15:43, Alexander Gordeev wrote:
> On Tue, Mar 31, 2026 at 11:11:22PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> The only implication is "only this address/PTE range could be updated
>>> and that range may span one page table at most".
>>
>> Probably phrase it stronger. "No ptes outside of this range must be
>> updated" etc.
> 
> That turns out to be bit more complicated. The below cases do not fit
> such a strong requirement:
> 
> 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.

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

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

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

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

-- 
Cheers,

David