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

[Muchun Song <muchun.song@linux.dev>]

> On Jan 8, 2026, at 21:30, Kiryl Shutsemau <kas@kernel.org> wrote:
> 
> On Thu, Jan 08, 2026 at 12:32:47PM +0000, Kiryl Shutsemau wrote:
>> 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.
> 
> 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