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

[David Hildenbrand (Red Hat)]

> > 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.

Ah, I could have sworn you sent something out, but maybe these were 
preparations only. :)

> > 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.

So once that is in, even if we only allocate "struct folio" separately, 
the whole fake-head stuff can go away either way, as it is 
hugetlb->folio material only.

Which leaves the question whether we should consider Kiryl's patch set 
in the meantime here as something to merge.

Willy, what is the rough timeline until we can expect to see at least 
"struct folio" get allocated separately, and would this patch set here 
get in the way of doing so, or doesn't it really matter?

--
Cheers

David