| Message ID | 20211226083912.166512-2-wangkefeng.wang@huawei.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | mm: support huge vmalloc mapping on arm64/x86 | expand |
On 2021/12/26 16:39, Kefeng Wang wrote: > Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or > not enable huge vmalloc mappings by default, and this could make > more architectures to enable huge vmalloc mappings feature but > don't want to enable it by default. > > Add hugevmalloc=on/off parameter to enable or disable this feature > at boot time, nohugevmalloc is still supported and equivalent to > hugevmalloc=off. > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > .../admin-guide/kernel-parameters.txt | 12 ++++++++++++ > arch/powerpc/Kconfig | 1 + > mm/Kconfig | 7 +++++++ > mm/vmalloc.c | 18 +++++++++++++++++- > 4 files changed, 37 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 2fba82431efb..4107136097a6 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1629,6 +1629,18 @@ > If both parameters are enabled, hugetlb_free_vmemmap takes > precedence over memory_hotplug.memmap_on_memory. > > + > + hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC > + Format: { on | off } > + Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED. > + > + This parameter enables/disables kernel huge vmalloc > + mappings at boot time. > + > + on: Enable the feature > + off: Disable the feature > + Equivalent to: nohugevmalloc > + > hung_task_panic= > [KNL] Should the hung task detector generate panics. > Format: 0 | 1 > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index dea74d7717c0..d59b221be264 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -246,6 +246,7 @@ config PPC > select HAVE_STATIC_CALL if PPC32 > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_VIRT_CPU_ACCOUNTING > + select HUGE_VMALLOC_DEFAULT_ENABLED if HAVE_ARCH_HUGE_VMALLOC > select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE > select IOMMU_HELPER if PPC64 > select IRQ_DOMAIN > diff --git a/mm/Kconfig b/mm/Kconfig > index 356f4f2c779e..4ba91c0359bd 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -262,6 +262,13 @@ config HUGETLB_PAGE_SIZE_VARIABLE > HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available > on a platform. > > +config HUGE_VMALLOC_DEFAULT_ENABLED > + bool "Enable huge vmalloc mappings by default" > + depends on HAVE_ARCH_HUGE_VMALLOC > + help > + Enable huge vmalloc mappings by default, this value could be overridden > + by hugevmalloc=off|on. > + > config CONTIG_ALLOC > def_bool (MEMORY_ISOLATION && COMPACTION) || CMA > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d2a00ad4e1dd..3b6f99753816 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -58,7 +58,7 @@ static const unsigned int ioremap_max_page_shift = PAGE_SHIFT; > #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */ > > #ifdef CONFIG_HAVE_ARCH_HUGE_VMALLOC > -static bool __ro_after_init vmap_allow_huge = true; > +static bool __ro_after_init vmap_allow_huge = IS_ENABLED(CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED); > > static int __init set_nohugevmalloc(char *str) > { > @@ -66,6 +66,22 @@ static int __init set_nohugevmalloc(char *str) > return 0; > } > early_param("nohugevmalloc", set_nohugevmalloc); > + > +static int __init set_hugevmalloc(char *str) > +{ > + if (!str) > + return -EINVAL; > + > + if (!strcmp(str, "on")) > + vmap_allow_huge = true; > + else if (!strcmp(str, "off")) > + vmap_allow_huge = true; should vmap_allow_huge=false, my mistake... > + else > + return -EINVAL; > + > + return 0; > +} > +early_param("hugevmalloc=", set_hugevmalloc); > #else /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */ > static const bool vmap_allow_huge = false; > #endif /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
Le 26/12/2021 à 09:39, Kefeng Wang a écrit : > Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or > not enable huge vmalloc mappings by default, and this could make > more architectures to enable huge vmalloc mappings feature but > don't want to enable it by default. > > Add hugevmalloc=on/off parameter to enable or disable this feature > at boot time, nohugevmalloc is still supported and equivalent to > hugevmalloc=off. Is there a real added value to have the user be able to select that ? If the architecture supports it, is there any good reason to not use it ? Why not just do like PPC and enable it by default ? Why should it be enabled by default on PPC but disabled by default on ARM64 and X86 ? > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > .../admin-guide/kernel-parameters.txt | 12 ++++++++++++ > arch/powerpc/Kconfig | 1 + > mm/Kconfig | 7 +++++++ > mm/vmalloc.c | 18 +++++++++++++++++- > 4 files changed, 37 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 2fba82431efb..4107136097a6 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1629,6 +1629,18 @@ > If both parameters are enabled, hugetlb_free_vmemmap takes > precedence over memory_hotplug.memmap_on_memory. > > + > + hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC > + Format: { on | off } > + Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED. > + > + This parameter enables/disables kernel huge vmalloc > + mappings at boot time. > + > + on: Enable the feature > + off: Disable the feature > + Equivalent to: nohugevmalloc > + > hung_task_panic= > [KNL] Should the hung task detector generate panics. > Format: 0 | 1 > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index dea74d7717c0..d59b221be264 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -246,6 +246,7 @@ config PPC > select HAVE_STATIC_CALL if PPC32 > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_VIRT_CPU_ACCOUNTING > + select HUGE_VMALLOC_DEFAULT_ENABLED if HAVE_ARCH_HUGE_VMALLOC > select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE > select IOMMU_HELPER if PPC64 > select IRQ_DOMAIN > diff --git a/mm/Kconfig b/mm/Kconfig > index 356f4f2c779e..4ba91c0359bd 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -262,6 +262,13 @@ config HUGETLB_PAGE_SIZE_VARIABLE > HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available > on a platform. > > +config HUGE_VMALLOC_DEFAULT_ENABLED > + bool "Enable huge vmalloc mappings by default" > + depends on HAVE_ARCH_HUGE_VMALLOC > + help > + Enable huge vmalloc mappings by default, this value could be overridden > + by hugevmalloc=off|on. > + > config CONTIG_ALLOC > def_bool (MEMORY_ISOLATION && COMPACTION) || CMA > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d2a00ad4e1dd..3b6f99753816 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -58,7 +58,7 @@ static const unsigned int ioremap_max_page_shift = PAGE_SHIFT; > #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */ > > #ifdef CONFIG_HAVE_ARCH_HUGE_VMALLOC > -static bool __ro_after_init vmap_allow_huge = true; > +static bool __ro_after_init vmap_allow_huge = IS_ENABLED(CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED); > > static int __init set_nohugevmalloc(char *str) > { > @@ -66,6 +66,22 @@ static int __init set_nohugevmalloc(char *str) > return 0; > } > early_param("nohugevmalloc", set_nohugevmalloc); > + > +static int __init set_hugevmalloc(char *str) > +{ > + if (!str) > + return -EINVAL; > + > + if (!strcmp(str, "on")) > + vmap_allow_huge = true; > + else if (!strcmp(str, "off")) > + vmap_allow_huge = true; > + else > + return -EINVAL; > + > + return 0; > +} > +early_param("hugevmalloc=", set_hugevmalloc); > #else /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */ > static const bool vmap_allow_huge = false; > #endif /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
On 2021/12/27 1:36, Christophe Leroy wrote: > > Le 26/12/2021 à 09:39, Kefeng Wang a écrit : >> Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or >> not enable huge vmalloc mappings by default, and this could make >> more architectures to enable huge vmalloc mappings feature but >> don't want to enable it by default. >> >> Add hugevmalloc=on/off parameter to enable or disable this feature >> at boot time, nohugevmalloc is still supported and equivalent to >> hugevmalloc=off. > > Is there a real added value to have the user be able to select that ? > > If the architecture supports it, is there any good reason to not use it ? There are some disadvantages[1], one of the main concerns is the possible memory waste, we have backported this feature to our kernel 5.10, but our downstream in our some scenario(especially in embedded), they don't want it enabled by default, and others want it, this is why patch1 comes. > > Why not just do like PPC and enable it by default ? Why should it be > enabled by default on PPC but disabled by default on ARM64 and X86 ? The PPC is default enabled, we don't changes this behavior. Maybe upstream is not care about this, as I said in cover-letter, if arm64/x86 don't want patch1, we could only just select config to enable it. Let's wait for more feedback. Thanks. [1] https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/
On Mon, Dec 27, 2021 at 09:44:24AM +0800, Kefeng Wang wrote: > > On 2021/12/27 1:36, Christophe Leroy wrote: > > > > Le 26/12/2021 à 09:39, Kefeng Wang a écrit : > > > Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or > > > not enable huge vmalloc mappings by default, and this could make > > > more architectures to enable huge vmalloc mappings feature but > > > don't want to enable it by default. > > > > > > Add hugevmalloc=on/off parameter to enable or disable this feature > > > at boot time, nohugevmalloc is still supported and equivalent to > > > hugevmalloc=off. > > > > Is there a real added value to have the user be able to select that ? > > > > If the architecture supports it, is there any good reason to not use it ? > > There are some disadvantages[1], one of the main concerns is the possible > > memory waste, we have backported this feature to our kernel 5.10, but our > > downstream in our some scenario(especially in embedded), they don't want > > it enabled by default, and others want it, this is why patch1 comes. > > > > > Why not just do like PPC and enable it by default ? Why should it be > > enabled by default on PPC but disabled by default on ARM64 and X86 ? > > The PPC is default enabled, we don't changes this behavior. > > Maybe upstream is not care about this, as I said in cover-letter, if > arm64/x86 > > don't want patch1, we could only just select config to enable it. > > Let's wait for more feedback. We should not have different defaults by architecture. Either we change the default for PPC, or x86 & arm should have the same default as PPC.
On 2021/12/27 11:19, Matthew Wilcox wrote: > On Mon, Dec 27, 2021 at 09:44:24AM +0800, Kefeng Wang wrote: >> On 2021/12/27 1:36, Christophe Leroy wrote: >>> Le 26/12/2021 à 09:39, Kefeng Wang a écrit : >>>> Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or >>>> not enable huge vmalloc mappings by default, and this could make >>>> more architectures to enable huge vmalloc mappings feature but >>>> don't want to enable it by default. >>>> >>>> Add hugevmalloc=on/off parameter to enable or disable this feature >>>> at boot time, nohugevmalloc is still supported and equivalent to >>>> hugevmalloc=off. >>> Is there a real added value to have the user be able to select that ? >>> >>> If the architecture supports it, is there any good reason to not use it ? >> There are some disadvantages[1], one of the main concerns is the possible >> >> memory waste, we have backported this feature to our kernel 5.10, but our >> >> downstream in our some scenario(especially in embedded), they don't want >> >> it enabled by default, and others want it, this is why patch1 comes. >> >>> Why not just do like PPC and enable it by default ? Why should it be >>> enabled by default on PPC but disabled by default on ARM64 and X86 ? >> The PPC is default enabled, we don't changes this behavior. >> >> Maybe upstream is not care about this, as I said in cover-letter, if >> arm64/x86 >> >> don't want patch1, we could only just select config to enable it. >> >> Let's wait for more feedback. > We should not have different defaults by architecture. Either we change > the default for PPC, or x86 & arm should have the same default as PPC. Ok, since HUGE_VMALLOC_DEFAULT_ENABLED is introduced, we could make it default y, not only select it on PPC, then the ppc/arm64/x86 have same default value. And if someone don't want it, they could not enable this config. Meanwhile hugevmalloc=on/off to make this feature to enable/disable at boot time. I will add some explanation and resend it, thanks. > .
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2fba82431efb..4107136097a6 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1629,6 +1629,18 @@ If both parameters are enabled, hugetlb_free_vmemmap takes precedence over memory_hotplug.memmap_on_memory. + + hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC + Format: { on | off } + Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED. + + This parameter enables/disables kernel huge vmalloc + mappings at boot time. + + on: Enable the feature + off: Disable the feature + Equivalent to: nohugevmalloc + hung_task_panic= [KNL] Should the hung task detector generate panics. Format: 0 | 1 diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index dea74d7717c0..d59b221be264 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -246,6 +246,7 @@ config PPC select HAVE_STATIC_CALL if PPC32 select HAVE_SYSCALL_TRACEPOINTS select HAVE_VIRT_CPU_ACCOUNTING + select HUGE_VMALLOC_DEFAULT_ENABLED if HAVE_ARCH_HUGE_VMALLOC select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE select IOMMU_HELPER if PPC64 select IRQ_DOMAIN diff --git a/mm/Kconfig b/mm/Kconfig index 356f4f2c779e..4ba91c0359bd 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -262,6 +262,13 @@ config HUGETLB_PAGE_SIZE_VARIABLE HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available on a platform. +config HUGE_VMALLOC_DEFAULT_ENABLED + bool "Enable huge vmalloc mappings by default" + depends on HAVE_ARCH_HUGE_VMALLOC + help + Enable huge vmalloc mappings by default, this value could be overridden + by hugevmalloc=off|on. + config CONTIG_ALLOC def_bool (MEMORY_ISOLATION && COMPACTION) || CMA diff --git a/mm/vmalloc.c b/mm/vmalloc.c index d2a00ad4e1dd..3b6f99753816 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -58,7 +58,7 @@ static const unsigned int ioremap_max_page_shift = PAGE_SHIFT; #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */ #ifdef CONFIG_HAVE_ARCH_HUGE_VMALLOC -static bool __ro_after_init vmap_allow_huge = true; +static bool __ro_after_init vmap_allow_huge = IS_ENABLED(CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED); static int __init set_nohugevmalloc(char *str) { @@ -66,6 +66,22 @@ static int __init set_nohugevmalloc(char *str) return 0; } early_param("nohugevmalloc", set_nohugevmalloc); + +static int __init set_hugevmalloc(char *str) +{ + if (!str) + return -EINVAL; + + if (!strcmp(str, "on")) + vmap_allow_huge = true; + else if (!strcmp(str, "off")) + vmap_allow_huge = true; + else + return -EINVAL; + + return 0; +} +early_param("hugevmalloc=", set_hugevmalloc); #else /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */ static const bool vmap_allow_huge = false; #endif /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or not enable huge vmalloc mappings by default, and this could make more architectures to enable huge vmalloc mappings feature but don't want to enable it by default. Add hugevmalloc=on/off parameter to enable or disable this feature at boot time, nohugevmalloc is still supported and equivalent to hugevmalloc=off. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- .../admin-guide/kernel-parameters.txt | 12 ++++++++++++ arch/powerpc/Kconfig | 1 + mm/Kconfig | 7 +++++++ mm/vmalloc.c | 18 +++++++++++++++++- 4 files changed, 37 insertions(+), 1 deletion(-)