Re: [PATCH RFC v2 00/20] mm: optimize unnecessary loads due to ptep_get() and friends out

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

On 7/22/26 19:30, Yeoreum Yun wrote:
>> One of my nits about v1 was that it didn't really frame the series
>> precisely. It talks about "optimization" instead of fundamentally
>> changing the way that the kernel deals with folded page table levels.
>>
>> The optimization that this *wants* to talk about kinda falls out of that
>> refactoring. It's not really the core of the series, IMNHO.
>>
>> This series effectively changes the rules about where and how folded
>> page table levels can be manipulated. In doing that, the door is opened
>> to optimizing out the unnecessary loads.
> 
> I see. might the title and the cover letter should be reparsed.
> Thanks to remind it again :)

While v1 changed "where and how folded page table levels can be manipulated"
more drastically, v2 leaves most of set_pgd/... working for now, and really only
changes how pgd_get() operates.

With v2, there is mostly only a change for page table walkers that use
pgd_get(): while the existing model already made all these levels be skipped in
most places except in ptdump code, we now also have to skip them in ptdump code.

So yes, that should be clearly spelled out: as long as pgd_get() is not
involved, set_pgd()/pgd_page_vaddr()... will keep working as is.

The moment someone switches to pgd_get() with folded page tables (like riscv
already does), set_pgd() is disallowed, and modifications on the actual level
must be performed. As discussed, a common helper for vmalloc faults would
already minimize the pain quite a lot in that scenario.

While we should make that clearer in the patch description, I am wondering
whether we should also add some basic MM documentation for folded page tables,
where we at least explain the current state-of-the-art (what's ignored when
traversing, why does "no_p4d" actually mean "pgd helpers are dummies and p4d
helpers implement the real logic").

-- 
Cheers,

David