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.8 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=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 54F2AC6379F for ; Fri, 20 Nov 2020 08:36:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E2CDA2224C for ; Fri, 20 Nov 2020 08:36:14 +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="y56aEgz7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727165AbgKTIgB (ORCPT ); Fri, 20 Nov 2020 03:36:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725766AbgKTIgA (ORCPT ); Fri, 20 Nov 2020 03:36:00 -0500 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F0E0C0613CF for ; Fri, 20 Nov 2020 00:35:59 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id 10so7190974pfp.5 for ; Fri, 20 Nov 2020 00:35:59 -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=v8+mXQPphnEalmROxh/i56omdGOqj/p5Ii14lIEaDXc=; b=y56aEgz7bs4GaAyDTrLBYqViMqxej7ZiXuaI4A7Y82jFPMu4C0G1GOGfoK39NqZu0J 44J4qDdpeFais5XnAu7FsZJcejS94IyDqJ82BLgq3qHL5UQCXYnAx+Skwu70mXMBR8wa oLiZkB+NrihfcRK+/wCV6LpooBJm2feHkUJ5YPbEYncR4snTvn2gBbM7UDBjZJpKH4bZ WN4qbfLNOhGOpPwOJWEmAeC2caSUnlYcgrAdd/g89rcxcZWVCKAyo6Hl/SkOLm3xgqNh qgrNz1ZOOcNINEaj3vKcDr7HTjoSfbxrrexuEzTO4NwxqB72mRVdmdjJyyAGF1Ri7rBd yqIw== 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=v8+mXQPphnEalmROxh/i56omdGOqj/p5Ii14lIEaDXc=; b=bTkBe1EcCwlRcpCO44PhwqeyRlDGCS7BVsYI5FMmWBhkGXZ4DYVHuXxdT1D3bFy2jd F9ZiiW25X9HBkWPxAQByVP60zW24cEJytG8EyEWd4aWQ29G/048SQk5EPKUUDpNhgYm/ 5xWxZV5VGrVGtx42rtRCFmhx2VSOT62NU80PG65G2fezGgEX6s7ftFUBaZa9wN+fRe6/ NEdrk30dNfK/56fW2ydEFCYXbNmZlh1pLYBO2tsysynsLBEsEM6M+aVmavnNFwRph5Jc Wl1k4RtyBPVgEZaNndAnlxkkBW1Ii5F2GpZYJwJ2RBjgvWO3LCDqlrD/Zi+vP2OFrJPr oHbA== X-Gm-Message-State: AOAM5335AfnC26RNLnY/X8Km7U/IaaKrB5joOcCPQmBreYfG5TZE2/lq D6qj3jJwZI4gEdTDV0UCbKVKcJCqtlwOG13K2O5OHw== X-Google-Smtp-Source: ABdhPJzY472bsCYM6XW2O521h+JXC9KpHBxbY6cz52QULFVtH4t2TDj/9BfSmdxmuvEjiO7bZe0KIe0KIZyLWMDKe0I= X-Received: by 2002:a17:90b:88b:: with SMTP id bj11mr9288264pjb.229.1605861358891; Fri, 20 Nov 2020 00:35:58 -0800 (PST) MIME-Version: 1.0 References: <20201120064325.34492-1-songmuchun@bytedance.com> <20201120064325.34492-4-songmuchun@bytedance.com> <20201120074950.GB3200@dhcp22.suse.cz> In-Reply-To: <20201120074950.GB3200@dhcp22.suse.cz> From: Muchun Song Date: Fri, 20 Nov 2020 16:35:16 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v5 03/21] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP To: Michal Hocko 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 , "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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 20, 2020 at 3:49 PM Michal Hocko wrote: > > On Fri 20-11-20 14:43:07, 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. > > Why is the config option necessary? Are code savings with the feature > disabled really worth it? I can see that your later patch adds a kernel > command line option. I believe that is a more reasonable way to control > the feature. I would argue that this should be an opt-in rather than > opt-out though. Think of users of pre-built (e.g. distribution kernels) > who might be interested in the feature. Yet you cannot assume that such > a kernel would enable the feature with its overhead to all hugetlb > users. Now the config option may be necessary. Because the feature only supports x86. While other architectures need some code to support this feature. In the future, we will implement it on other architectures. Then, we can remove this option. Also, this config option is not optional. It is default by the CONFIG_HUGETLB_PAGE. If the kernel selects the CONFIG_HUGETLB_PAGE, the CONFIG_ HUGETLB_PAGE_FREE_VMEMMAP is also selected. The user only can disable this feature by boot command line :). Thanks. > > That being said, unless there are huge advantages to introduce a > config option I would rather not add it because our config space is huge > already and the more we add the more future code maintainance that will > add. If you want the config just for dependency checks then fine by me. Yeah, it is only for dependency checks :) > > > 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; > > > > 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. > > + > > + 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. > > + > > config MEMFD_CREATE > > def_bool TMPFS || HUGETLBFS > > > > -- > > 2.11.0 > > -- > Michal Hocko > SUSE Labs -- Yours, Muchun 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.8 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 353A1C5519F for ; Fri, 20 Nov 2020 08:36:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 81A3922249 for ; Fri, 20 Nov 2020 08:36:05 +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="y56aEgz7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 81A3922249 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 9AB7A6B0036; Fri, 20 Nov 2020 03:36:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9320C6B005C; Fri, 20 Nov 2020 03:36:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 820A96B0068; Fri, 20 Nov 2020 03:36:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 461116B0036 for ; Fri, 20 Nov 2020 03:36:04 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CE0291F1A for ; Fri, 20 Nov 2020 08:36:03 +0000 (UTC) X-FDA: 77504139006.10.bait51_25011132734a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id A569516A4BC for ; Fri, 20 Nov 2020 08:36:02 +0000 (UTC) X-HE-Tag: bait51_25011132734a X-Filterd-Recvd-Size: 7056 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 08:36:01 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id b63so7159485pfg.12 for ; Fri, 20 Nov 2020 00:35:59 -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=v8+mXQPphnEalmROxh/i56omdGOqj/p5Ii14lIEaDXc=; b=y56aEgz7bs4GaAyDTrLBYqViMqxej7ZiXuaI4A7Y82jFPMu4C0G1GOGfoK39NqZu0J 44J4qDdpeFais5XnAu7FsZJcejS94IyDqJ82BLgq3qHL5UQCXYnAx+Skwu70mXMBR8wa oLiZkB+NrihfcRK+/wCV6LpooBJm2feHkUJ5YPbEYncR4snTvn2gBbM7UDBjZJpKH4bZ WN4qbfLNOhGOpPwOJWEmAeC2caSUnlYcgrAdd/g89rcxcZWVCKAyo6Hl/SkOLm3xgqNh qgrNz1ZOOcNINEaj3vKcDr7HTjoSfbxrrexuEzTO4NwxqB72mRVdmdjJyyAGF1Ri7rBd yqIw== 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=v8+mXQPphnEalmROxh/i56omdGOqj/p5Ii14lIEaDXc=; b=gn5OqXq43yNZqLQhI/FY12F+Zu3vB8dO/xXp8m5UC/iGpVn8PoCRcOF0HWoDJqZrkt 5MJWmnfqz3Lqxe4eWTdMHB1a0/1qlGEuKwur4XbEqgj34kct2oDzmNBhhg+1tlTRzaF8 IafBMfUr7zQCy9R84RTwslY8Pa7GKVLlki5JmRxwqwBbVH0ZmSgwKfmeKXTEE5EpuVu0 npXZ3mXVEXiaanB/a2Ym+K9uHhvKpfVl0uSEN0o/BEQzmKaCUnP7P/piFOOpVjFTZyJu VqbekYCuu3lAUp7gSNdbeqMgBgPmQrtu7YsUH+lC1nFthzrknFf6wVefcFIbshf7QnNR XQlQ== X-Gm-Message-State: AOAM533CWaQIA2ESrzKvdrDcsAndxGkPhNLFjMMSU46X29eXU6qMNTw+ pe45BhkODbaNieAsJ/5tQwtV9EXNuFp9bBtQ6R5jXA== X-Google-Smtp-Source: ABdhPJzY472bsCYM6XW2O521h+JXC9KpHBxbY6cz52QULFVtH4t2TDj/9BfSmdxmuvEjiO7bZe0KIe0KIZyLWMDKe0I= X-Received: by 2002:a17:90b:88b:: with SMTP id bj11mr9288264pjb.229.1605861358891; Fri, 20 Nov 2020 00:35:58 -0800 (PST) MIME-Version: 1.0 References: <20201120064325.34492-1-songmuchun@bytedance.com> <20201120064325.34492-4-songmuchun@bytedance.com> <20201120074950.GB3200@dhcp22.suse.cz> In-Reply-To: <20201120074950.GB3200@dhcp22.suse.cz> From: Muchun Song Date: Fri, 20 Nov 2020 16:35:16 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v5 03/21] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP To: Michal Hocko 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 , "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 Fri, Nov 20, 2020 at 3:49 PM Michal Hocko wrote: > > On Fri 20-11-20 14:43:07, 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. > > Why is the config option necessary? Are code savings with the feature > disabled really worth it? I can see that your later patch adds a kernel > command line option. I believe that is a more reasonable way to control > the feature. I would argue that this should be an opt-in rather than > opt-out though. Think of users of pre-built (e.g. distribution kernels) > who might be interested in the feature. Yet you cannot assume that such > a kernel would enable the feature with its overhead to all hugetlb > users. Now the config option may be necessary. Because the feature only supports x86. While other architectures need some code to support this feature. In the future, we will implement it on other architectures. Then, we can remove this option. Also, this config option is not optional. It is default by the CONFIG_HUGETLB_PAGE. If the kernel selects the CONFIG_HUGETLB_PAGE, the CONFIG_ HUGETLB_PAGE_FREE_VMEMMAP is also selected. The user only can disable this feature by boot command line :). Thanks. > > That being said, unless there are huge advantages to introduce a > config option I would rather not add it because our config space is huge > already and the more we add the more future code maintainance that will > add. If you want the config just for dependency checks then fine by me. Yeah, it is only for dependency checks :) > > > 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; > > > > 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. > > + > > + 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. > > + > > config MEMFD_CREATE > > def_bool TMPFS || HUGETLBFS > > > > -- > > 2.11.0 > > -- > Michal Hocko > SUSE Labs -- Yours, Muchun