Re: [PATCHv2 02/14] mm/sparse: Check memmap alignment

[Matthew Wilcox]

On Thu, Jan 08, 2026 at 12:08:35AM +0100, David Hildenbrand (Red Hat) wrote:
> > > "Then we make page->compound_head point to the dynamically allocated memdesc
> > > rather than the first page. Then we can transition to the above layout. "
> > 
> 
> Sorry for the late reply, it's been a bit crazy over here.
> 
> > I am not sure I understand how it is going to work.
> > 
> 
> I don't recall all the details that Willy shared over the last years while
> working on folios, but I will try to answer as best as I can from the top of
> my head. (there are plenty of resources on the list, on the web, in his
> presentations etc.).
> 
> > 32-byte layout indicates that flags will stay in the statically
> > allocated part, but most (all?) flags are in the head page and we would
> > need a way to redirect from tail to head in the statically allocated
> > pages.
> 
> When working with folios we will never go through the head page flags.
> That's why Willy has incrementally converted most folio code that worked on
> pages to work on folios.

A little more detail here:

 - Zone/Node/Section stay in page->flags and are replicated to
   folio->flags
 - HWPoison stays in page->flags
 - Reserved stays in page->flags
 - AnonExclusive stays in page->flags
 - Writeback/Referenced/Uptodate/Dirty/LRU/Active/Workingset/Owner1/
   Owner2/Reclaim/Swapbacked/Unevictable/Dropbehind/MLocked/Young/Idle
   all exist only in folio->flags
 - Head/Private/Private2 all go away
 - Locked & Waiters are ... complicated.  I'll elaborate if there's
   demand.
 - I haven't put any effort into analyzing the Xen flags.
 - HasHWPoisoned/LargeRmappable/PartiallyMapped all move to folio->flags

> When the program was called "2025" I considered it very ambitious :) Now I
> consider it ambitious. I think Willy already shared early versions of the
> "struct slab" split and the "struct ptdesc" split recently on the list.

ptdesc, yes.  Slab is still in progress.

> For quite some time there will be a magical config option that will switch
> between both layouts. I'd assume that things will get more complicated if we
> suddenly have a "compound_head/folio" pointer and a "compound_info" pointer
> at the same time.

What I'm hoping to get to is a point where calling compound_head() on
a page which is part of a folio is a BUG.  You should only be calling
page_folio() on a page which is part of a folio -- because there's nothing
useful to find in the head page.  So compound_head (or compound_info) can
share space with page->memdesc.  For now I've actually put page->memdesc
adjacent to page->compound_head, for no reason that I can recall.

I had thought that calling page_folio() on a page that's not part of
a folio would also be a BUG(), but now I think it's better to quietly
return NULL.  That's based on my experience working with slab and ptdesc.