| Message ID | 20201120064325.34492-4-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Free some vmemmap pages of hugetlb page | expand |
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. 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. > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > 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
On Fri, Nov 20, 2020 at 3:49 PM Michal Hocko <mhocko@suse.com> 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 <songmuchun@bytedance.com> > > --- > > 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
On Fri 20-11-20 16:35:16, Muchun Song wrote: [...] > > 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 :) OK, I must have misread the definition to think that it requires user to enable explicitly. Anyway this feature cannot be really on by default due to overhead. So the command line option default has to be flipped.
On Fri, Nov 20, 2020 at 4:47 PM Michal Hocko <mhocko@suse.com> wrote: > > On Fri 20-11-20 16:35:16, Muchun Song wrote: > [...] > > > 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 :) > > OK, I must have misread the definition to think that it requires user to > enable explicitly. > > Anyway this feature cannot be really on by default due to overhead. So > the command line option default has to be flipped. Got it. Thanks for your suggestion. > > -- > Michal Hocko > SUSE Labs
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
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 <songmuchun@bytedance.com> --- arch/x86/mm/init_64.c | 2 +- fs/Kconfig | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-)