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 X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D220EC2D0A3 for ; Mon, 9 Nov 2020 13:52:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 63ADF206B2 for ; Mon, 9 Nov 2020 13:52:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 63ADF206B2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 872BC6B0068; Mon, 9 Nov 2020 08:52:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8037F6B006C; Mon, 9 Nov 2020 08:52:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EBBD6B006E; Mon, 9 Nov 2020 08:52:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3F1AC6B0068 for ; Mon, 9 Nov 2020 08:52:21 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DEFEB1EE6 for ; Mon, 9 Nov 2020 13:52:20 +0000 (UTC) X-FDA: 77465019240.24.guide33_3e164a9272ec Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id C41A91A4A5 for ; Mon, 9 Nov 2020 13:52:20 +0000 (UTC) X-HE-Tag: guide33_3e164a9272ec X-Filterd-Recvd-Size: 4313 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Nov 2020 13:52:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id ABC11ABD1; Mon, 9 Nov 2020 13:52:18 +0000 (UTC) Date: Mon, 9 Nov 2020 14:52:15 +0100 From: Oscar Salvador To: Muchun Song Cc: corbet@lwn.net, mike.kravetz@oracle.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, rdunlap@infradead.org, oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, almasrymina@google.com, rientjes@google.com, willy@infradead.org, mhocko@suse.com, duanxiongchun@bytedance.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 03/21] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Message-ID: <20201109135215.GA4778@localhost.localdomain> References: <20201108141113.65450-1-songmuchun@bytedance.com> <20201108141113.65450-4-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201108141113.65450-4-songmuchun@bytedance.com> 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: On Sun, Nov 08, 2020 at 10:10:55PM +0800, Muchun Song wrote: > The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure > whether to enable the feature of freeing unused vmemmap associated > with HugeTLB pages. Now only support x86. > > Signed-off-by: Muchun Song > --- > arch/x86/mm/init_64.c | 2 +- > fs/Kconfig | 16 ++++++++++++++++ > mm/bootmem_info.c | 3 +-- > 3 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > index 0a45f062826e..0435bee2e172 100644 > --- a/arch/x86/mm/init_64.c > +++ b/arch/x86/mm/init_64.c > @@ -1225,7 +1225,7 @@ static struct kcore_list kcore_vsyscall; > > static void __init register_page_bootmem_info(void) > { > -#ifdef CONFIG_NUMA > +#if defined(CONFIG_NUMA) || defined(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) > int i; > > for_each_online_node(i) > diff --git a/fs/Kconfig b/fs/Kconfig > index 976e8b9033c4..21b8d39a9715 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -245,6 +245,22 @@ config HUGETLBFS > config HUGETLB_PAGE > def_bool HUGETLBFS > > +config HUGETLB_PAGE_FREE_VMEMMAP > + bool "Free unused vmemmap associated with HugeTLB pages" > + default y > + depends on X86 > + depends on HUGETLB_PAGE > + depends on SPARSEMEM_VMEMMAP > + depends on HAVE_BOOTMEM_INFO_NODE > + help > + There are many struct page structures associated with each HugeTLB > + page. But we only use a few struct page structures. In this case, > + it wastes some memory. It is better to free the unused struct page > + structures to buddy system which can save some memory. For > + architectures that support it, say Y here. > + > + If unsure, say N. I am not sure the above is useful for someone who needs to decide whether he needs/wants to enable this or not. I think the above fits better in a Documentation part. I suck at this, but what about the following, or something along those lines? " When using SPARSEMEM_VMEMMAP, the system can save up some memory from pre-allocated HugeTLB pages when they are not used. 6 pages per 2MB HugeTLB page and 4095 per 1GB HugeTLB page. When the pages are going to be used or freed up, the vmemmap array representing that range needs to be remapped again and the pages we discarded earlier need to be rellocated again. Therefore, this is a trade-off between saving memory and increasing time in allocation/free path. " It would be also great to point out that this might be a trade-off between saving up memory and increasing the cost of certain operations on allocation/free path. That is why I mentioned it there. -- Oscar Salvador SUSE L3