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: <3v5hdubqnil6w54kimvbgapghj7irjp7xuqma6uxtsrpvj22ph@6t47vsevdwyi>
Date: Fri, 5 Dec 2025 21:41:18 +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 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

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ