From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
<linuxppc-dev@lists.ozlabs.org>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<x86@kernel.org>, <linux-arm-kernel@lists.infradead.org>
Cc: Nicholas Piggin <npiggin@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Michael Ellerman <mpe@ellerman.id.au>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
Date: Sun, 26 Dec 2021 16:39:10 +0800 [thread overview]
Message-ID: <20211226083912.166512-2-wangkefeng.wang@huawei.com> (raw)
In-Reply-To: <20211226083912.166512-1-wangkefeng.wang@huawei.com>
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;
+ 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 */
--
2.26.2
next prev parent reply other threads:[~2021-12-26 8:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-26 8:39 [PATCH 0/3] mm: support huge vmalloc mapping on arm64/x86 Kefeng Wang
2021-12-26 8:39 ` Kefeng Wang [this message]
2021-12-26 8:33 ` [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
2021-12-26 17:36 ` Christophe Leroy
2021-12-27 1:44 ` Kefeng Wang
2021-12-27 3:19 ` Matthew Wilcox
2021-12-27 6:14 ` Kefeng Wang
2021-12-26 8:39 ` [PATCH 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
2021-12-26 8:39 ` [PATCH 3/3] x86: " Kefeng Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211226083912.166512-2-wangkefeng.wang@huawei.com \
--to=wangkefeng.wang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).