linux-kernel - Re: [PATCH 00/11] mm/hugetlb: Eliminate fake head pages from vmemmap optimization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ysvhofzg5mdtvxfujdsmffkuqna72pr52ehrpglmlhxnvwstas@xurgptkgtnbe>
Date: Fri, 5 Dec 2025 20:54:49 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	Muchun Song <muchun.song@...ux.dev>, Matthew Wilcox <willy@...radead.org>, 
	Oscar Salvador <osalvador@...e.de>, Mike Rapoport <rppt@...nel.org>, 
	Vlastimil Babka <vbabka@...e.cz>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 
	Zi Yan <ziy@...dia.com>, Baoquan He <bhe@...hat.com>, Michal Hocko <mhocko@...e.com>, 
	Johannes Weiner <hannes@...xchg.org>, Jonathan Corbet <corbet@....net>, 
	Usama Arif <usamaarif642@...il.com>, kernel-team@...a.com, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH 00/11] mm/hugetlb: Eliminate fake head pages from vmemmap
 optimization

On Fri, Dec 05, 2025 at 09:44:30PM +0100, David Hildenbrand (Red Hat) wrote:
> On 12/5/25 21:33, Kiryl Shutsemau wrote:
> > On Fri, Dec 05, 2025 at 09:16:08PM +0100, David Hildenbrand (Red Hat) wrote:
> > > On 12/5/25 20:43, Kiryl Shutsemau wrote:
> > > > This series removes "fake head pages" from the HugeTLB vmemmap
> > > > optimization (HVO) by changing how tail pages encode their relationship
> > > > to the head page.
> > > > 
> > > > It simplifies compound_head() and page_ref_add_unless(). Both are in the
> > > > hot path.
> > > > 
> > > > Background
> > > > ==========
> > > > 
> > > > HVO reduces memory overhead by freeing vmemmap pages for HugeTLB pages
> > > > and remapping the freed virtual addresses to a single physical page.
> > > > Previously, all tail page vmemmap entries were remapped to the first
> > > > vmemmap page (containing the head struct page), creating "fake heads" -
> > > > tail pages that appear to have PG_head set when accessed through the
> > > > deduplicated vmemmap.
> > > > 
> > > > This required special handling in compound_head() to detect and work
> > > > around fake heads, adding complexity and overhead to a very hot path.
> > > > 
> > > > New Approach
> > > > ============
> > > > 
> > > > For architectures/configs where sizeof(struct page) is a power of 2 (the
> > > > common case), this series changes how position of the head page is encoded
> > > > in the tail pages.
> > > > 
> > > > Instead of storing a pointer to the head page, the ->compound_info
> > > > (renamed from ->compound_head) now stores a mask.
> > > 
> > > (we're in the merge window)
> > > 
> > > That doesn't seem to be suitable for the memdesc plans, where we want all
> > > tail pages do directly point at the allocated memdesc (e.g., struct folio),
> > > no?
> > 
> > Sure. My understanding is that it is going to eliminate a need in
> > compound_head() completely. I don't see the conflict so far.
> 
> Right. All compound_head pointers will point at the allocated memdesc.
> 
> Would we still have to detect fake head pages though (at least for some
> transition period)?

If we need to detect if the memdesc is tail it should be as trivial as
comparing the given memdesc to the memdesc - 1. If they match, you are
looking at the tail.

But I don't think we wound need it.

The memdesc itself doesn't hold anything you want to touch if don't hold
reference to the folio. You wound need dereference memdesc and after it
you don't care if the memdesc it tail.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov