Re: [PATCH 00/11] mm/hugetlb: Eliminate fake head pages from vmemmap optimization
From: Kiryl Shutsemau
Date: Fri Dec 05 2025 - 15:33:34 EST
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.
--
Kiryl Shutsemau / Kirill A. Shutemov