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

On Jan 8, 2026, at 21:30, Kiryl Shutsemau [off-list ref] wrote:

On Thu, Jan 08, 2026 at 12:32:47PM +0000, Kiryl Shutsemau wrote:

quoted

On Thu, Jan 08, 2026 at 12:08:35AM +0100, David Hildenbrand (Red Hat) wrote:

quoted

quoted

quoted

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

quoted

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

quoted

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.

quoted

quoted

quoted

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.

quoted

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.

Or other option is to get this patchset upstream (I need to fix/test few
things still) and revert it later when (if?) memdesc lands.

What do you think?

It seems the merge of memdesc is still some time away? If it’s going to
take a while, my personal preference is to merge it first and then decide
whether to revert the changes based on actual needs.

Thanks.

-- 
 Kiryl Shutsemau / Kirill A. Shutemov