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,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 DFE3FC5517A for ; Mon, 9 Nov 2020 14:20:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 428AE20897 for ; Mon, 9 Nov 2020 14:20:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bytedance-com.20150623.gappssmtp.com header.i=@bytedance-com.20150623.gappssmtp.com header.b="anyEXQNB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 428AE20897 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6258F6B0036; Mon, 9 Nov 2020 09:20:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5ADFE6B005C; Mon, 9 Nov 2020 09:20:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 476526B005D; Mon, 9 Nov 2020 09:20:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 1C30D6B0036 for ; Mon, 9 Nov 2020 09:20:41 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BC6C2180AD801 for ; Mon, 9 Nov 2020 14:20:40 +0000 (UTC) X-FDA: 77465090640.11.coast84_4d17d34272ed Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 9860B180F8B81 for ; Mon, 9 Nov 2020 14:20:40 +0000 (UTC) X-HE-Tag: coast84_4d17d34272ed X-Filterd-Recvd-Size: 6703 Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Nov 2020 14:20:39 +0000 (UTC) Received: by mail-pf1-f194.google.com with SMTP id c66so2589127pfa.4 for ; Mon, 09 Nov 2020 06:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yzZSafk58bq+f5L2n1A+XJgmXIfKfqr55EsbHaz5ToU=; b=anyEXQNBxl/WPiGhQQNwmAQb+fQoGWo0vJCypbVU0olYHgcNgdGNMOWRmxfxeUtv3o g26pAqMiAJOuq6UnzUPj5YGG+tQY8LLQaNhEpp1i2NBpd1rk3QXgSjo3rFc7n4A3rgRT 2migm/LzuplMv3qzhqSicOFWm9bKmd8hcj+WFa8U9Bvl1MadZP78fp68EqVPtOeThjkF 1FVJmmjavutK+fiGUf9u3YvoXYozI5tKWIP/YFbT7b3r8hcbG+AX8eOKYUa3HalOCEsK wYJoi97fMNPqIHVk3ZtTA4+Sm84h7F7d+jSzQrpK8GataVUIRXUTh5imfrXTBMUYi4jG 48lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yzZSafk58bq+f5L2n1A+XJgmXIfKfqr55EsbHaz5ToU=; b=IcR1JSnumDZT9lj6NZMj7InbAfjjw136zy2EjmjOYiDnbVz4JX2gahuJyNG1aDnP2A EIRP0aMFI/BKpeo9d3strDrlV+kJfeMDQFtDktdcef8Ah9CACbijqyRs/iq7C3i39HnI trmWI3yz12sTGmzfyX5/BC+b7jjh3rcI1rAAOcI9fUj3LFUhxed++AO4AY4PXEb/6Mnf EAzNe4bm9ne3ye3WkQc9PLlu6WQJDxPWc2fK2bxDPmnelJsN+/FkRa/NNcqaNtsyVUNM rKuSHa0aFhaqsw031vMxln/NlgB55eqRBwi0N9mSgl7Pk8uVyXTGxK2RRcuwLGevbf58 wzlQ== X-Gm-Message-State: AOAM531XxGjIvP5FJiOWOpGyHIXSgcQmcPnRPrtwpWo1MU94XnZKzFt1 JVHszCkhdLFwa1FqNEBf3TYN8B1J69jAvTsWnyOPcQ== X-Google-Smtp-Source: ABdhPJxkpM77kBmju2XOjMh8n98tAVXTI9znLZLfuG3dhhF1nJ7YKOpkysiIxpvhmPZsNVGS0wGQ7jgSEAlN/Hk9bPM= X-Received: by 2002:a65:5383:: with SMTP id x3mr12825717pgq.341.1604931638489; Mon, 09 Nov 2020 06:20:38 -0800 (PST) MIME-Version: 1.0 References: <20201108141113.65450-1-songmuchun@bytedance.com> <20201108141113.65450-4-songmuchun@bytedance.com> <20201109135215.GA4778@localhost.localdomain> In-Reply-To: <20201109135215.GA4778@localhost.localdomain> From: Muchun Song Date: Mon, 9 Nov 2020 22:20:02 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v3 03/21] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP To: Oscar Salvador Cc: Jonathan Corbet , Mike Kravetz , Thomas Gleixner , mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , viro@zeniv.linux.org.uk, Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Michal Hocko , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" 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 Mon, Nov 9, 2020 at 9:52 PM Oscar Salvador wrote: > > 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. > " Will do. Thanks for your suggestions. > > 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. OK, I will add this to the Documentation part, thanks. > > -- > Oscar Salvador > SUSE L3 -- Yours, Muchun