Re: [PATCH v7 2/4] s390/mm: Batch PTE updates in lazy MMU mode

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

On Thu, Oct 01, 2026 at 10:21:43AM +0200, Heiko Carstens wrote:
> On Thu, Oct 01, 2026 at 10:00:55AM +0200, Alexander Gordeev wrote:
> > On Mon, Aug 24, 2026 at 12:40:48PM +0200, Heiko Carstens wrote:
> > > > +static __always_inline bool is_lazy_mmu_active(void)
> > > > +{
> > > > +	if (__is_defined(__DECOMPRESSOR))
> > > > +		return false;
> > > > +	if (!get_lowcore()->lazy_mmu_count)
> > > > +		return false;
> > > 
> > > I guess there is opportunity to generate better code here using an
> > > alternative and using a flag output constraint too.
> > 
> > It is only CY and LT instructions that make sense for me.
> > Here is what I came up with:
> 
> ...
> 
> > As result instead of gcc code:
> > 
> > 	lghi	%r8,0
> > 	lt	%r1,1032(%r8)
> > 	je	...
> > 
> > We get more or less the same:
> > 
> > 	lhi	%r1,0
> > 	cy	%r1,1032
> > 	jne	...
> > 
> > The only benefit is [zero] "d" (0) could sometimes avoid LHI if a
> > zeroed register is already around. But also the KASAN coverage is
> > not generated.
> > 
> > Does it make sense to go ahead whith the alternative?
> 
> Not really. But why is lazy_mmu_count 32 bit? Do you expect a nesting
> level of 2^32? :) If you would reduce that to one byte you could use
> tmy or cliy.

Good point. But still, do you think it worth dropping the KASAN check?