From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B35E5C433F5 for ; Fri, 4 Mar 2022 15:21:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C74C8D0002; Fri, 4 Mar 2022 10:21:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 277138D0001; Fri, 4 Mar 2022 10:21:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 165DB8D0002; Fri, 4 Mar 2022 10:21:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 069078D0001 for ; Fri, 4 Mar 2022 10:21:32 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AD7CB181C3044 for ; Fri, 4 Mar 2022 15:21:31 +0000 (UTC) X-FDA: 79207067982.17.E6C168A Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) by imf03.hostedemail.com (Postfix) with ESMTP id C7BCB20029 for ; Fri, 4 Mar 2022 15:21:30 +0000 (UTC) Received: from localhost (unknown [IPv6:2601:281:8300:104d::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 458762B2; Fri, 4 Mar 2022 15:21:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 458762B2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1646407289; bh=AhHVtg/426WKGFSGTFlnmzgHgc/rCgdo3CzDRsHi0+U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I3ux9Nk937rQeghegNLHqwynXlUDCPBjc6XCc5xU2k9JBfKg23znK5PB2A7+q5Sb1 wi/IqKiBgXGlqHy8fWTkBD0R3cmC7B79cgCjsiYX3N3voagDXFFhX6ugQAYH6cz1WB GLULLzOYIYtaLmHWI+8sGYicc8t/uZ9/0r08F2YFoVH8og07/Fb5QLvPvCX+6OfUgk M2RXgXqAbkRwUQNm+JBxUw0gZ2JaTkWFQb75GREUjc1T5i8loQXva/A+M+yE2dXbo4 1ZtWBAJ5zXMT+frhWE8LP5FmBN7VPxeRT64AgHtBge4eiT6R1dRPxPH6moli6eiy+h bzSfHxwdaAZPw== From: Jonathan Corbet To: Joao Martins , linux-mm@kvack.org Cc: Dan Williams , Vishal Verma , Matthew Wilcox , Jason Gunthorpe , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org, Joao Martins Subject: Re: [PATCH v7 3/5] mm/hugetlb_vmemmap: move comment block to Documentation/vm In-Reply-To: <20220303213252.28593-4-joao.m.martins@oracle.com> References: <20220303213252.28593-1-joao.m.martins@oracle.com> <20220303213252.28593-4-joao.m.martins@oracle.com> Date: Fri, 04 Mar 2022 08:21:28 -0700 Message-ID: <87r17hhhfr.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C7BCB20029 X-Stat-Signature: drzxnmt6pktt1pmua81qfg49ebp7hn8r Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=lwn.net header.s=20201203 header.b=I3ux9Nk9; spf=pass (imf03.hostedemail.com: domain of corbet@lwn.net designates 45.79.88.28 as permitted sender) smtp.mailfrom=corbet@lwn.net; dmarc=none X-Rspam-User: X-HE-Tag: 1646407290-682088 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Joao Martins writes: > In preparation for device-dax for using hugetlbfs compound page tail > deduplication technique, move the comment block explanation into a > common place in Documentation/vm. > > Cc: Muchun Song > Cc: Mike Kravetz > Suggested-by: Dan Williams > Signed-off-by: Joao Martins > Reviewed-by: Muchun Song > Reviewed-by: Dan Williams > --- > Documentation/vm/index.rst | 1 + > Documentation/vm/vmemmap_dedup.rst | 175 +++++++++++++++++++++++++++++ > mm/hugetlb_vmemmap.c | 168 +-------------------------- > 3 files changed, 177 insertions(+), 167 deletions(-) > create mode 100644 Documentation/vm/vmemmap_dedup.rst Thanks for remembering to add this to the index.rst file! That said, I get the impression you didn't actually build the docs afterward and look at the result; there are a number of things here that won't render the way you might like. > diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst > index 44365c4574a3..2fb612bb72c9 100644 > --- a/Documentation/vm/index.rst > +++ b/Documentation/vm/index.rst > @@ -37,5 +37,6 @@ algorithms. If you are looking for advice on simply allocating memory, see the > transhuge > unevictable-lru > vmalloced-kernel-stacks > + vmemmap_dedup > z3fold > zsmalloc > diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/vm/vmemmap_dedup.rst > new file mode 100644 > index 000000000000..8143b2ce414d > --- /dev/null > +++ b/Documentation/vm/vmemmap_dedup.rst > @@ -0,0 +1,175 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +.. _vmemmap_dedup: This label isn't needed, I'd take it out. > +================================== > +Free some vmemmap pages of HugeTLB > +================================== > + > +The struct page structures (page structs) are used to describe a physical > +page frame. By default, there is a one-to-one mapping from a page frame to > +it's corresponding page struct. > + > +HugeTLB pages consist of multiple base page size pages and is supported by > +many architectures. See hugetlbpage.rst in the Documentation directory for > +more details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB > +are currently supported. Since the base page size on x86 is 4KB, a 2MB > +HugeTLB page consists of 512 base pages and a 1GB HugeTLB page consists of > +4096 base pages. For each base page, there is a corresponding page struct. > + > +Within the HugeTLB subsystem, only the first 4 page structs are used to > +contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides > +this upper limit. The only 'useful' information in the remaining page structs > +is the compound_head field, and this field is the same for all tail pages. > + > +By removing redundant page structs for HugeTLB pages, memory can be returned > +to the buddy allocator for other uses. > + > +Different architectures support different HugeTLB pages. For example, the > +following table is the HugeTLB page size supported by x86 and arm64 > +architectures. Because arm64 supports 4k, 16k, and 64k base pages and > +supports contiguous entries, so it supports many kinds of sizes of HugeTLB > +page. > + > ++--------------+-----------+-----------------------------------------------+ > +| Architecture | Page Size | HugeTLB Page Size | > ++--------------+-----------+-----------+-----------+-----------+-----------+ > +| x86-64 | 4KB | 2MB | 1GB | | | > ++--------------+-----------+-----------+-----------+-----------+-----------+ > +| | 4KB | 64KB | 2MB | 32MB | 1GB | > +| +-----------+-----------+-----------+-----------+-----------+ > +| arm64 | 16KB | 2MB | 32MB | 1GB | | > +| +-----------+-----------+-----------+-----------+-----------+ > +| | 64KB | 2MB | 512MB | 16GB | | > ++--------------+-----------+-----------+-----------+-----------+-----------+ > + > +When the system boot up, every HugeTLB page has more than one struct page > +structs which size is (unit: pages): > + > + struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE This, for example, needs to be in a literal block or you won't get what you expect; that's true of all of the code samples and ascii-art sections. Easiest way to do that is to end the preceding text line with :: instead of : Thanks, jon