From nobody Sun Feb 8 05:26:54 2026 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 0388C3451BA; Thu, 18 Dec 2025 15:10:20 +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=1766070620; cv=none; b=ZJwZJmVXwv9RcIYllrVlsIEh1pDemM0Gj71FOZDa5S2VqY0zTMmNdXKb8At9XY0+I3B9Kbkdl579qkKe82BDdJAdjlD6Y2f6uOGdeswn4sExhN9nbyx/otT7ioYY78O8r4j8/F+ZFQXg6xMAvFLMfW+ID5To7++7dqLaMSHK0dw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766070620; c=relaxed/simple; bh=qHJKjreeIB8u6+GC7KtXgFelYE26+ueZzxyId6y/BHA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qfv9eFtP3l6sRyDFoVU+O3fNx+f9YA6tdMMI2fjKjCSUVOHZUPy23BnoYMljDKe0IaIHo9tL/SRf1+W4XLZIiP7YqzA1si073b4wQhU1KYjkZCZ3ehOzzbISpLQ3KYLhc/AHRMRHi4MP+HuVabXa86ldYrsqRHCk142llaiV3ms= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j5pE5e8i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j5pE5e8i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 236BEC116C6; Thu, 18 Dec 2025 15:10:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766070619; bh=qHJKjreeIB8u6+GC7KtXgFelYE26+ueZzxyId6y/BHA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j5pE5e8i3AKjkR8X26UUaRqpDhXaxWIJP0ehbs1RS+1zq9BnrSEf286kgh7Qu6/Ls XGLlHSahXuhHL34g9WL1KNM+oKpopVdzyztmbr0ALoN4bwBvU259mk89csSgIsmD8E 4XUOEGSVDm3pbksY+UU7y+RKy9Ar0GUNtETuMWvxUBsGPF1v9RChz52Rc8D8Y+2zvw wFHsfOzJcBilraBa/s8XcIO8NYrqm8j3BN+7GWkk6DPsI+C8oF0KBHrluvtazBeEuW EfIRTGeQhbZPMShfvqfCL74EOOqGguuvQ6D/V29n1yUnLOsOii7tKov1bDRmwu7sjM 6YCwEEsnf/vlQ== Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id 73C68F4007D; Thu, 18 Dec 2025 10:10:18 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 18 Dec 2025 10:10:18 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdegheejgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvfevufffkffojghfgggtgfesthekredtredtjeenucfhrhhomhepmfhirhihlhcu ufhhuhhtshgvmhgruhcuoehkrghssehkvghrnhgvlhdrohhrgheqnecuggftrfgrthhtvg hrnhepffekffefudfgiedujeehfeelheetveetgfevhfevteehheekhfejfeehgfeljeev necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepkhhirh hilhhlodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieduudeivdeiheeh qddvkeeggeegjedvkedqkhgrsheppehkvghrnhgvlhdrohhrghesshhhuhhtvghmohhvrd hnrghmvgdpnhgspghrtghpthhtohepvddtpdhmohguvgepshhmthhpohhuthdprhgtphht thhopegrkhhpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtoh epmhhutghhuhhnrdhsohhngheslhhinhhugidruggvvhdprhgtphhtthhopegurghvihgu sehkvghrnhgvlhdrohhrghdprhgtphhtthhopeifihhllhihsehinhhfrhgruggvrggurd horhhgpdhrtghpthhtohepuhhsrghmrggrrhhifheigedvsehgmhgrihhlrdgtohhmpdhr tghpthhtohepfhhvughlsehgohhoghhlvgdrtghomhdprhgtphhtthhopehoshgrlhhvrg guohhrsehsuhhsvgdruggvpdhrtghpthhtoheprhhpphhtsehkvghrnhgvlhdrohhrghdp rhgtphhtthhopehvsggrsghkrgesshhushgvrdgtii X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Dec 2025 10:10:17 -0500 (EST) From: Kiryl Shutsemau To: Andrew Morton , Muchun Song , David Hildenbrand , Matthew Wilcox , Usama Arif , Frank van der Linden Cc: Oscar Salvador , Mike Rapoport , Vlastimil Babka , Lorenzo Stoakes , Zi Yan , Baoquan He , Michal Hocko , Johannes Weiner , Jonathan Corbet , kernel-team@meta.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Kiryl Shutsemau Subject: [PATCHv2 14/14] hugetlb: Update vmemmap_dedup.rst Date: Thu, 18 Dec 2025 15:09:45 +0000 Message-ID: <20251218150949.721480-15-kas@kernel.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20251218150949.721480-1-kas@kernel.org> References: <20251218150949.721480-1-kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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. Signed-off-by: Kiryl Shutsemau --- Documentation/mm/vmemmap_dedup.rst | 60 +++++++++++++----------------- 1 file changed, 26 insertions(+), 34 deletions(-) diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_= dedup.rst index 1863d88d2dcb..a0c4c79d6922 100644 --- a/Documentation/mm/vmemmap_dedup.rst +++ b/Documentation/mm/vmemmap_dedup.rst @@ -124,33 +124,35 @@ Here is how things look before optimization:: | | +-----------+ =20 -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 rem= aining -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 pa= ge`` -will be used for each HugeTLB page. This will allow us to free the remaini= ng -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 rema= ining +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 pow= er-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. =20 Here is how things look after remapping:: =20 - HugeTLB struct pages(8 pages) page frame(8 pa= ges) - +-----------+ ---virt_to_page---> +-----------+ mapping to +---------= --+ - | | | 0 | -------------> | 0 = | - | | +-----------+ +---------= --+ - | | | 1 | ---------------^ ^ ^ ^ ^ = ^ ^ - | | +-----------+ | | | | = | | - | | | 2 | -----------------+ | | | = | | - | | +-----------+ | | | = | | - | | | 3 | -------------------+ | | = | | - | | +-----------+ | | = | | - | | | 4 | ---------------------+ | = | | - | PMD | +-----------+ | = | | - | level | | 5 | -----------------------+ = | | - | mapping | +-----------+ = | | - | | | 6 | -------------------------= + | - | | +-----------+ = | - | | | 7 | -------------------------= --+ + HugeTLB struct pages(8 pages) page fr= ame + +-----------+ ---virt_to_page---> +-----------+ mapping to +---------= -------+ + | | | 0 | -------------> | 0 = | + | | +-----------+ +---------= -------+ + | | | 1 | ------=E2=94=90 + | | +-----------+ | + | | | 2 | ------=E2=94=BC +-= ---------------+ + | | +-----------+ | | vmemmap_= tail | + | | | 3 | ------=E2=94=BC------> | = shared for the | + | | +-----------+ | | struct h= state | + | | | 4 | ------=E2=94=BC +-= ---------------+ + | | +-----------+ | + | | | 5 | ------=E2=94=BC + | PMD | +-----------+ | + | level | | 6 | ------=E2=94=BC + | mapping | +-----------+ | + | | | 7 | ------=E2=94=98 | | +-----------+ | | | | @@ -172,16 +174,6 @@ The contiguous bit is used to increase the mapping siz= e at the pmd and pte (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. =20 -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 Hug= eTLB -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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --=20 2.51.2