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

[Kiryl Shutsemau <kas@kernel.org>]

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.
> 
> For example, PageUptodate() does a
> 
> 	folio_test_uptodate(page_folio(page));
> 
> The flags in the 32-byte layout will be used by some non-folio things for
> which we won't allocate memdescs (just yet) (e.g., free pages in the buddy
> and other things that does not require a lot of metadata). Some of these
> flags will be moved into the memdesc pointer in the future as the conversion
> proceeeds.

Okay, makes sense.

> > > The "memdesc" could be a pointer to a "struct folio" that is allocated from
> > > the slab.
> > > 
> > > So in the new memdesc world, all pages part of a folio will point at the
> > > allocated "struct folio", not the head page where "struct folio" currently
> > > overlays "struct page".
> > > 
> > > That would mean that the proposal in this patch set will have to be reverted
> > > again.
> > > 
> > > 
> > > At LPC, Willy said that he wants to have something out there in the first
> > > half of 2026.
> > 
> > Okay, seems ambitious to me.
> 
> 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.
> 
> > 
> > Last time I asked, we had no idea how much performance would additional
> > indirection cost us. Do we have a clue?
> 
> I raised that in the past, and I think the answer I got was that
> 
> (a) We always had these indirection cost when going from tail page to
>     head page / folio.
> (b) We must convert the code to do as little page_folio() as possible.
>     That's why we saw so much code conversion to stop working on pages
>     and only work on folios.
> 
> There are certainly cases where we cannot currently avoid the indirection,
> like when we traverse a page table and go
> 
> 	pfn -> page -> folio
> 
> and cannot simply go
> 
> 	pfn -> folio
> 
> On the bright side, we'll lose the head-page checks and can simply
> dereference the pointer.
> 
> I don't know whether Willy has more information yet, but I would assume that
> in most cases this will be similar to the performance summary in your cover
> letter: "... has shown either no change or only a slight improvement within
> the noise.", just that it will be "only a slight degradation within the
> noise". :)
> 
> We'll learn I guess, in particular which other page -> folio conversions
> cannot be optimized out by caching the folio.
> 
> 
> 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.
> 
> But it's really Willy who has the concept in mind as he is very likely right
> now busy writing some of that code.
> 
> I'm just the messenger.
> 
> :)
> 
> [I would hope that Willy could share his thoughts]

If you or Willy think that this patch will impede memdesc progress, I am
okay not pushing this patchset upstream.

I was really excited when I found this trick to get rid of fake heads.
But ultimately, it is a clean up. I failed to find a performance win I
hoped for.

Also, I try to understand what 32-byte layout means for fake heads.
_refcount in struct page is going to 0 and refcounting happens on folios.
So I wounder if we can all pages identical (no tail pages per se) and
avoid fake heads this way?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov