From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 387084779A0 for ; Fri, 27 Feb 2026 20:10:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772223018; cv=none; b=h8rs5JTXTuReD8Ky+kIwo5+w2Oa4+dlj0MY/NrDenW5p1rV4CMsDNplTpL6w2mfLcOBrg2egzYQ+G5dmjhzDcanexabXDsLATQ/IB8hX0a/Ysdd2rYRvDscc03C+593ynsXoBxanaF6DASWjjGCQCQ6Kf0KOmp2kPRY0wKmSZ3U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772223018; c=relaxed/simple; bh=RTr6yIJl14V4OoYkRACxHIqWDYh7jENql0IfRsHO9hU=; h=Date:To:From:Subject:Message-Id; b=gYWCS6prYUgPbBHY3JGDsdy0jW5fpcrRAKDtlxIN/7DermwtYhzt2Wbmpey0UFZyBv+wxih9BfsvLnlcvIM9nF4l/tGqo2adPfhdnfAyHSrDOZpGcrcQiv7rhTCPYSPrwM37QGuLsPSUfHzyGjmIphrPP2k5u1KQJyFG/1dPec0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=s/NZdDIt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="s/NZdDIt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C777EC19421; Fri, 27 Feb 2026 20:10:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1772223017; bh=RTr6yIJl14V4OoYkRACxHIqWDYh7jENql0IfRsHO9hU=; h=Date:To:From:Subject:From; b=s/NZdDItyFLTmfEQqjbdXYS2qPu8lTKG4INWW7XyASFPnCPCHH13OfzSlW48AUOfw 1zaRb2+kJXOVabw1J9bMFb8uH4BhujAyGGFmRfOdPGD8iVgR++CBf8rjZKprXaxj4B ZaM5vQl519vpA8IP9xVcZYRpKZoQTznGveuHIxPA= Date: Fri, 27 Feb 2026 12:10:17 -0800 To: mm-commits@vger.kernel.org,ziy@nvidia.com,willy@infradead.org,vbabka@suse.cz,usamaarif642@gmail.com,rppt@kernel.org,roman.gushchin@linux.dev,rientjes@google.com,paul.walmsley@sifive.com,palmer@dabbelt.com,osalvador@suse.de,muchun.song@linux.dev,mhocko@suse.com,lorenzo.stoakes@oracle.com,kernel@xen0n.name,harry.yoo@oracle.com,hannes@cmpxchg.org,fvdl@google.com,david@kernel.org,corbet@lwn.net,cl@gentwo.org,chenhuacai@kernel.org,bhe@redhat.com,aou@eecs.berkeley.edu,alex@ghiti.fr,kas@kernel.org,akpm@linux-foundation.org From: Andrew Morton Subject: + hugetlb-update-vmemmap_deduprst.patch added to mm-new branch Message-Id: <20260227201017.C777EC19421@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: hugetlb: update vmemmap_dedup.rst has been added to the -mm mm-new branch. Its filename is hugetlb-update-vmemmap_deduprst.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/hugetlb-update-vmemmap_deduprst.patch This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Kiryl Shutsemau Subject: hugetlb: update vmemmap_dedup.rst Date: Fri, 27 Feb 2026 19:42:55 +0000 Update the documentation regarding vmemmap optimization for hugetlb to reflect the changes in how the kernel maps the tail pages. Fake heads no longer exist. Remove their description. Link: https://lkml.kernel.org/r/20260227194302.274384-18-kas@kernel.org Signed-off-by: Kiryl Shutsemau Reviewed-by: Muchun Song Reviewed-by: David Hildenbrand (Arm) Cc: Albert Ou Cc: Alexandre Ghiti Cc: Baoquan He Cc: Christoph Lameter Cc: David Rientjes Cc: Frank van der Linden Cc: Harry Yoo Cc: Huacai Chen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Lorenzo Stoakes Cc: Matthew Wilcox (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Oscar Salvador Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Roman Gushchin Cc: Usama Arif Cc: Vlastimil Babka Cc: WANG Xuerui Cc: Zi Yan Signed-off-by: Andrew Morton --- Documentation/mm/vmemmap_dedup.rst | 60 +++++++++++---------------- 1 file changed, 26 insertions(+), 34 deletions(-) --- a/Documentation/mm/vmemmap_dedup.rst~hugetlb-update-vmemmap_deduprst +++ a/Documentation/mm/vmemmap_dedup.rst @@ -124,33 +124,35 @@ Here is how things look before optimizat | | +-----------+ -The value of page->compound_info is the same for all tail pages. The first -page of ``struct page`` (page 0) associated with the HugeTLB page contains the 4 -``struct page`` necessary to describe the HugeTLB. The only use of the remaining -pages of ``struct page`` (page 1 to page 7) is to point to page->compound_info. -Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of ``struct page`` -will be used for each HugeTLB page. This will allow us to free the remaining -7 pages to the buddy allocator. +The first page of ``struct page`` (page 0) associated with the HugeTLB page +contains the 4 ``struct page`` necessary to describe the HugeTLB. The remaining +pages of ``struct page`` (page 1 to page 7) are tail pages. + +The optimization is only applied when the size of the struct page is a power-of-2 +In this case, all tail pages of the same order are identical. See +compound_head(). This allows us to remap the tail pages of the vmemmap to a +shared, read-only page. The head page is also remapped to a new page. This +allows the original vmemmap pages to be freed. Here is how things look after remapping:: - HugeTLB struct pages(8 pages) page frame(8 pages) - +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ - | | | 0 | -------------> | 0 | - | | +-----------+ +-----------+ - | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ - | | +-----------+ | | | | | | - | | | 2 | -----------------+ | | | | | - | | +-----------+ | | | | | - | | | 3 | -------------------+ | | | | - | | +-----------+ | | | | - | | | 4 | ---------------------+ | | | - | PMD | +-----------+ | | | - | level | | 5 | -----------------------+ | | - | mapping | +-----------+ | | - | | | 6 | -------------------------+ | - | | +-----------+ | - | | | 7 | ---------------------------+ + HugeTLB struct pages(8 pages) page frame (new) + +-----------+ ---virt_to_page---> +-----------+ mapping to +----------------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +----------------+ + | | | 1 | ------┐ + | | +-----------+ | + | | | 2 | ------┼ +----------------------------+ + | | +-----------+ | | A single, per-node page | + | | | 3 | ------┼------> | frame shared among all | + | | +-----------+ | | hugepages of the same size | + | | | 4 | ------┼ +----------------------------+ + | | +-----------+ | + | | | 5 | ------┼ + | PMD | +-----------+ | + | level | | 6 | ------┼ + | mapping | +-----------+ | + | | | 7 | ------┘ | | +-----------+ | | | | @@ -172,16 +174,6 @@ The contiguous bit is used to increase t (last) level. So this type of HugeTLB page can be optimized only when its size of the ``struct page`` structs is greater than **1** page. -Notice: The head vmemmap page is not freed to the buddy allocator and all -tail vmemmap pages are mapped to the head vmemmap page frame. So we can see -more than one ``struct page`` struct with ``PG_head`` (e.g. 8 per 2 MB HugeTLB -page) associated with each HugeTLB page. The ``compound_head()`` can handle -this correctly. There is only **one** head ``struct page``, the tail -``struct page`` with ``PG_head`` are fake head ``struct page``. We need an -approach to distinguish between those two different types of ``struct page`` so -that ``compound_head()`` can return the real head ``struct page`` when the -parameter is the tail ``struct page`` but with ``PG_head``. - Device DAX ========== _ Patches currently in -mm which might be from kas@kernel.org are mm-move-max_folio_order-definition-to-mmzoneh.patch mm-change-the-interface-of-prep_compound_tail.patch mm-rename-the-compound_head-field-in-the-struct-page-to-compound_info.patch mm-move-set-clear_compound_head-next-to-compound_head.patch riscv-mm-align-vmemmap-to-maximal-folio-size.patch loongarch-mm-align-vmemmap-to-maximal-folio-size.patch mm-rework-compound_head-for-power-of-2-sizeofstruct-page.patch mm-sparse-check-memmap-alignment-for-compound_info_has_mask.patch mm-hugetlb-defer-vmemmap-population-for-bootmem-hugepages.patch mm-hugetlb-refactor-code-around-vmemmap_walk.patch x86-vdso-undefine-config_hugetlb_page_optimize_vmemmap-for-vdso32.patch mm-hugetlb-remove-fake-head-pages.patch mm-drop-fake-head-checks.patch hugetlb-remove-vmemmap_synchronize_rcu.patch mm-hugetlb-remove-hugetlb_optimize_vmemmap_key-static-key.patch mm-remove-the-branch-from-compound_head.patch hugetlb-update-vmemmap_deduprst.patch mm-slab-use-compound_head-in-page_slab.patch