Re: [RFC PATCH 10/34] x86: mm: carve out the generic compile-time folded pgtable case in effective_prot()

Hi,

> > On 7/13/26 23:40, Dave Hansen wrote:
> > > On 7/13/26 14:17, David Hildenbrand (Arm) wrote:
> > >>> To me, the double READ_ONCE() is a non-issue.
> > >> To other arch maintainers, it is!
> > > 
> > > Ahh, so it seems like Christophe in ppc32 land was looking at this more
> > > like a regression that needed to get fixed.
> > 
> > Yes, exactly. :)
> > 
> > And I agree that it is something we should be optimizing.
> > 
> > > 
> > > Christophe, just out of curiosity, was this something that was causing
> > > you practical problems like measurable performance regressions, or was
> > > it really just insane code generation that seems unacceptably suboptimal?
> > 
> > I'd be curious about that as well. I mean, looking at the generated code
> > it's clear that it is suboptimal.
> > 
> > 
> > The solution space I see:
> > 
> > 
> > (1) Pass the result from e.g., pgdp_get() into p4d_get(), so it can just return 
> >     the value with folded p4ds.
> > 
> > That requires extreme amounts of churn in core-mm AFAIKS, so I don't see that as feasible.
> > 
> > 
> > (2) Rewrite folding code to make p4d_present() be a dummy instead of 
> >     pgd_present(), and make p4dp_get() return a dummy value.
> > 
> > ... a lot of churn across architectures. I'm sure we'll learn soon why it was done 
> > ike the way it is today in the first place. Something interesting to look at,
> > certainly, but a bit of a stretch just to optimize reads.
> > 
> > 
> > (3) Make folded pgdp_get() use an ordinary read instead of a READ_ONCE / dummy.
> > 
> > I don't like that, because we couldn't catch easily if the value is then
> > actually used some old/new code.
> > 
> > If pgd_present() etc are supposed to ignore the value, I'd rather have a mechanism
> > that enforces that the values are actually ignore in pgd_offset() etc as well.
> > 
> > 
> > (4) What we do in this series, but instead of forbidding set_pgd(), make it only 
> >     complain when we are passing in a dummy value.
> > 
> > The expectation is that it would avoid touching most architecture code in patch
> > 12 -> 27 and still prevent mistakes in the future.
> > 
> > @Yeoreum can you play with that and see what the end result would be?

If there's no comment anymore for (4), Could I post next version on tomorrow?

Thanks.

[...]

-- 
Sincerely,
Yeoreum Yun