Re: [PATCH v2 5/6] s390/mm: Batch PTE updates in lazy MMU mode

[Heiko Carstens <hca@linux.ibm.com>]

On Fri, Apr 24, 2026 at 03:10:42PM +0200, Alexander Gordeev wrote:
> On Thu, Apr 23, 2026 at 02:28:24PM +0200, Heiko Carstens wrote:
> > > +static inline void set_pte(pte_t *ptep, pte_t pte)
> > > +{
> > > +	if (!ipte_batch_set_pte(ptep, pte))
> > > +		__set_pte(ptep, pte);
> > > +}
> > 
> > Not sure if you analyzed it, but it looks like this might be the reason why
> > you see the fork() slowdown: every page table operation now comes with a
> > function call, even if is not needed.
> > 
> > I guess it would be helpful to add an early exit to the ipte_batch() inlines.
> > E.g. going back to the example above:
> > 
> > static inline
> > bool ipte_batch_ptep_test_and_clear_young(struct vm_area_struct *vma,
> > 					  unsigned long addr, pte_t *ptep,
> > 					  int *res)
> > {
> > 	if (__is_defined(__DECOMPRESSOR))
> > 		return false;
> > --->	if (unlikely(!ipte_batch_active()))
> > --->		return false;
> > 	return __ipte_batch_ptep_test_and_clear_young(vma, addr, ptep, res);
> > }
> > 
> > Where ipte_batch_active() would be an inline function which simply tests a bit
> > in lowcore.
> 
> The bit check alone would not be enough - it should be done with the
> preemption disabled. Then it would be something like lazy_mmu_mode(),
> but with one or more values in the lowcore instead of percpu variable
> (at least ::base_pte to check whether ptep falls into the active range).

What I meant: you need a one bit check in the inlined function, so you can
decide if it is even necessary to do the function call. More checking could be
done. However all the overhead of function calls will go away with single bit
check.

Or in other words: enter_ipte_batch() should set a bit in lowcore which can be
easily tested. This bit _also_ indicates that preemption is disabled. So all
the extra preempt disable / enable pairs within the page table primitives are
not needed, after this bit is present und used.

> > Just a general comment about the naming conventions: imho ipte_batch is not a
> > nice choice, since the name of the facility is "ipte range". However I would
> > abstract even more, since nobody knows if there will be a different
> > instruction or facility to achieve all of this in a better way.
> > 
> > Anyway... maybe rename the file simply to mmu.c or tlb.c and change the
> > function prefixes accordingly so we end up with shorter function names?
> 
> I would in turn suggest lazy_mmu_ prefix and lazy_mmu.c source name
> to emphasize it implements the generic lazy mmu mode.

Ok.

> At the same time
> keep ipte_batch (or ipte_range rather) in the implementation itself.

That still doesn't look to good to me, but can be solved at a later time.