linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Kiryl Shutsemau <kas@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	Muchun Song <muchun.song@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Zi Yan <ziy@nvidia.com>, Baoquan He <bhe@redhat.com>,
	Michal Hocko <mhocko@suse.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>,
	kernel-team@meta.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Usama Arif <usamaarif642@gmail.com>,
	Frank van der Linden <fvdl@google.com>
Subject: Re: [PATCHv2 02/14] mm/sparse: Check memmap alignment
Date: Fri, 9 Jan 2026 16:24:37 +0100	[thread overview]
Message-ID: <bed4daf8-9a35-4a88-bb35-2f178d8afa73@kernel.org> (raw)
In-Reply-To: <yup3hvfsn4tvfnv32mdf4yoabt4igb2lkvllfac72g3abdkovm@auqdaijzby7d>

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

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

I think it's quite nice as a cleanup, and if we wouldn't have memdescs 
on the horizon that essentially change the code completely in another 
direction (having all pages point to a struct folio, not just the tail 
pages), I wouldn't be bringing this up :)

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

Yes, for folios.

> So I wounder if we can all pages identical (no tail pages per se) and
> avoid fake heads this way?

That's the ultimate goal, yes. Essentially, all pages will point to the
memdesc, and there will not be a reason to check for head/fake-head etc.

I think initially, the compound-page concept might
still co-exist for some memdescs that we won't initially allocate 
separately.
But I don't know the details of that.

I know that the transition phase is tricky :)

Regarding reference and folios: yes exactly. When trying to get a 
reference, we'll spot in the memdesc field that this is a folio and try 
on the folio instead.

In the future, most pages will either be permanently frozen and not have 
a refcount (e.g., struct ptdesc), or have a refcount in their memdesc. 
In the transition, the location of the refcount depends on memdesc type 
(in memdesc vs. in page).

-- 
Cheers

David


  parent reply	other threads:[~2026-01-09 15:24 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 15:09 [PATCHv2 00/14] Kiryl Shutsemau
2025-12-18 15:09 ` [PATCHv2 01/14] mm: Move MAX_FOLIO_ORDER definition to mmzone.h Kiryl Shutsemau
2025-12-18 15:09 ` [PATCHv2 02/14] mm/sparse: Check memmap alignment Kiryl Shutsemau
2025-12-22  8:34   ` Muchun Song
2025-12-22 14:02     ` Kiryl Shutsemau
2025-12-22 14:18       ` David Hildenbrand (Red Hat)
2025-12-22 14:52         ` Kiryl Shutsemau
2025-12-22 14:59           ` Muchun Song
2025-12-22 14:55         ` Muchun Song
2025-12-23  9:38           ` David Hildenbrand (Red Hat)
2025-12-23 11:26             ` Muchun Song
2025-12-24 14:13             ` Kiryl Shutsemau
2026-01-07 23:08               ` David Hildenbrand (Red Hat)
2026-01-08 12:32                 ` Kiryl Shutsemau
2026-01-08 13:30                   ` Kiryl Shutsemau
2026-01-09  9:40                     ` Muchun Song
2026-01-09 15:24                   ` David Hildenbrand (Red Hat) [this message]
2026-01-09 21:48                 ` Matthew Wilcox
2025-12-22 14:49       ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 03/14] mm: Change the interface of prep_compound_tail() Kiryl Shutsemau
2025-12-22  2:55   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 04/14] mm: Rename the 'compound_head' field in the 'struct page' to 'compound_info' Kiryl Shutsemau
2025-12-22  3:00   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 05/14] mm: Move set/clear_compound_head() next to compound_head() Kiryl Shutsemau
2025-12-22  3:06   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 06/14] mm: Rework compound_head() for power-of-2 sizeof(struct page) Kiryl Shutsemau
2025-12-22  3:20   ` Muchun Song
2025-12-22 14:03     ` Kiryl Shutsemau
2025-12-23  8:37       ` Muchun Song
2025-12-22  7:57   ` Muchun Song
2025-12-22  9:45     ` Muchun Song
2025-12-22 14:49       ` Kiryl Shutsemau
2025-12-18 15:09 ` [PATCHv2 07/14] mm: Make page_zonenum() use head page Kiryl Shutsemau
2025-12-18 15:09 ` [PATCHv2 08/14] mm/hugetlb: Refactor code around vmemmap_walk Kiryl Shutsemau
2025-12-22  5:54   ` Muchun Song
2025-12-22 15:00     ` Kiryl Shutsemau
2025-12-22 15:11       ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 09/14] mm/hugetlb: Remove fake head pages Kiryl Shutsemau
2025-12-18 15:09 ` [PATCHv2 10/14] mm: Drop fake head checks Kiryl Shutsemau
2025-12-22  5:56   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 11/14] hugetlb: Remove VMEMMAP_SYNCHRONIZE_RCU Kiryl Shutsemau
2025-12-22  6:00   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 12/14] mm/hugetlb: Remove hugetlb_optimize_vmemmap_key static key Kiryl Shutsemau
2025-12-22  6:03   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 13/14] mm: Remove the branch from compound_head() Kiryl Shutsemau
2025-12-22  6:30   ` Muchun Song
2025-12-18 15:09 ` [PATCHv2 14/14] hugetlb: Update vmemmap_dedup.rst Kiryl Shutsemau
2025-12-22  6:20   ` Muchun Song
2025-12-18 22:18 ` [PATCHv2 00/14] Eliminate fake head pages from vmemmap optimization Kiryl Shutsemau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bed4daf8-9a35-4a88-bb35-2f178d8afa73@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=corbet@lwn.net \
    --cc=fvdl@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=rppt@kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox