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: <8e59b242-6311-48a7-b9f5-e698c4eccd2e@gmail.com>
Date: Sat, 6 Dec 2025 17:47:38 +0000
From: Usama Arif <usamaarif642@...il.com>
To: Kiryl Shutsemau <kas@...nel.org>,
 "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>,
 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 05/12/2025 21:41, Kiryl Shutsemau wrote:
> On Fri, Dec 05, 2025 at 10:34:48PM +0100, David Hildenbrand (Red Hat) wrote:
>> On 12/5/25 21:54, Kiryl Shutsemau wrote:
>>> 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.
>>
>> How could you assume memdesc - 1 exists without performing other checks?
> 
> Map zero page in front of every discontinuous vmemmap region :P
> 

I made an initial pass at reviewing the series. I think the best thing about this is that
someone looking at compound_head won't need to understand HVO to know how compound_head works,
so its a very nice clean up :)

Would be nice to make the commit messages more verbose, and also maybe add more comments about
why it works a certain way when sizeof struct page is a power of 2.

I don't know what the current memdesc plans are, so cant comment on that part.