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=-13.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,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 16E79C433FE for ; Mon, 7 Dec 2020 12:43:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 894A3233FC for ; Mon, 7 Dec 2020 12:43:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 894A3233FC 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 D61A98D0007; Mon, 7 Dec 2020 07:43:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D13788D0001; Mon, 7 Dec 2020 07:43:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C28E78D0007; Mon, 7 Dec 2020 07:43:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id ADDA58D0001 for ; Mon, 7 Dec 2020 07:43:10 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7BA39180AD80F for ; Mon, 7 Dec 2020 12:43:10 +0000 (UTC) X-FDA: 77566451340.27.drum10_4316614273de Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 5E00B3D663 for ; Mon, 7 Dec 2020 12:43:10 +0000 (UTC) X-HE-Tag: drum10_4316614273de X-Filterd-Recvd-Size: 6539 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Dec 2020 12:43:09 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id w4so8756855pgg.13 for ; Mon, 07 Dec 2020 04:43:07 -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=A3Sz9EwcVm7/laPzVL4k5X0ZCii9fn78txSMeems5dA=; b=JH1WGkTnBnWyl6t3H5VvF0TMMz5/m82Bz7apzt7nnrxQ6aH4/fP93IcsAur6/PdbLE HkNrx5vI94hkp+cayxPCE/4C4LkA6r7wu5OI7yLoLUbIsfb4WeKrYpGZ21T6d8OY4+sb n1WmlSDul/HFojHtb+cYnMtW9O6zws4A+srhsGrH7W/ekiDGwDPDXVUA1C9vgL6I93QQ kjyfdZLpV3F2wck6ymYtgRgpnwrZvnt09+LuDaPRpFRzEBezmhyeSjHXFrDsP8mJHtst i6PktA4JsnKm0RCMil2nv5UdF97zXfOMCiBeAcqk4BPK+nLygAhjk6ySa4whcUBRezi7 4vhA== 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=A3Sz9EwcVm7/laPzVL4k5X0ZCii9fn78txSMeems5dA=; b=WQO0G5puyuzMdDGOFZyd/4in3g6E7ulsazL+B+194Q3vpuJIDHzcGXtvMTyNwvV7Cp +frjU6eeAtESIEw/1ISiPPLC1bRSauxDMz8KaQ56Yx1AUT3Vxp0wXw7jZnSYLvq/7Dx3 uLrsTHBbEEmepwoAzZ52F74meoiqQ/8kw3m4xld5mIxz8eD9Yf0Lx4HLpl8dcvWAkcQ4 IGREVS188e6G/ECK63okwpqjtGSNpTcqHBPANxtNs/xamBswXO79F5hRL1ieKtZym1YR VlPFWYl/oyzGrgSE/gKSX7I70AXfR6jLCLjo1q6Qa1/fe25+dGMjkMgAm/Bej9nMyfR2 VAXA== X-Gm-Message-State: AOAM533fJUKUSsWL8tsz29pC0w2LqwV3fR1mPF/PwLovam6gcMizT38z X0mGkZPgsib/WTMEcHxKYMHsPlqS3WM301ldoOLV2A== X-Google-Smtp-Source: ABdhPJyYNVAE+tmn7JNGEOXOkwcqZO1ZbR7gnIDXJdT+G8tgPZRXcx7VJ7I/bEbnUunqR2+pYwcX4YYTWhsShd60dZ4= X-Received: by 2002:a17:902:ed0d:b029:da:c83b:5f40 with SMTP id b13-20020a170902ed0db02900dac83b5f40mr16065185pld.20.1607344986256; Mon, 07 Dec 2020 04:43:06 -0800 (PST) MIME-Version: 1.0 References: <20201130151838.11208-1-songmuchun@bytedance.com> <20201130151838.11208-4-songmuchun@bytedance.com> <2ec1d360-c8c8-eb7b-2afe-b75ee61cfcea@redhat.com> In-Reply-To: <2ec1d360-c8c8-eb7b-2afe-b75ee61cfcea@redhat.com> From: Muchun Song Date: Mon, 7 Dec 2020 20:42:29 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v7 03/15] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP To: David Hildenbrand 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 , Oscar Salvador , Michal Hocko , "Song Bao Hua (Barry Song)" , 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, Dec 7, 2020 at 8:19 PM David Hildenbrand wrote: > > On 30.11.20 16:18, 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. And this is just for dependency check. Now only > > support x86. > > x86 - i386 and x86-64? (I assume the latter only ;) ) Yeah, you are right. Only the latter support SPARSEMEM_VMEMMAP. > > > > > Signed-off-by: Muchun Song > > --- > > arch/x86/mm/init_64.c | 2 +- > > fs/Kconfig | 14 ++++++++++++++ > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > 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; > > > > Why does this hunk belong into this patch? Looks like this should go > into another patch. Of course can. But Mike suggests that it is better to use it when introducing a new config. Because this config depends on HAVE_BOOTMEM_INFO_NODE. And register_page_bootmem_info is aimed to register bootmem info. So maybe it is reasonable from this point of view. What is your opinion? > > > for_each_online_node(i) > > diff --git a/fs/Kconfig b/fs/Kconfig > > index 976e8b9033c4..4961dd488444 100644 > > --- a/fs/Kconfig > > +++ b/fs/Kconfig > > @@ -245,6 +245,20 @@ config HUGETLBFS > > config HUGETLB_PAGE > > def_bool HUGETLBFS > > > > +config HUGETLB_PAGE_FREE_VMEMMAP > > + def_bool HUGETLB_PAGE > > + depends on X86 > > + depends on SPARSEMEM_VMEMMAP > > + depends on HAVE_BOOTMEM_INFO_NODE > > + help > > + When using HUGETLB_PAGE_FREE_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 4094 per 1GB HugeTLB page. > > Calculations only apply to 4k base pages, no? No, if the base page is not 4k, we also can free 6 pages. For example: If the base page size is 64k, the PMD huge page size is 512MB. We also can free 6 pages(64k * 6) vmemmap. But maybe I should document this. Thanks. > (maybe generalize this a > bit or mention 4k base pages - I'm pretty sure we'll see the "depends on > X86" part fairly soon if this goes upstream) Yeah, it can be easy to adapt to different architectures. :) > > > -- > Thanks, > > David / dhildenb > -- Yours, Muchun