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
