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: Kefeng Wang <wangkefeng.wang@huawei.com>,
Matthew Wilcox <willy@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Nicholas Piggin <npiggin@gmail.com>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>
Subject: [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86
Date: Mon, 27 Dec 2021 22:59:00 +0800 [thread overview]
Message-ID: <20211227145903.187152-1-wangkefeng.wang@huawei.com> (raw)
Huge vmalloc mappings is supported on PPC[1], but this feature should
be not only used on PPC, it could be used on arch support HAVE_ARCH_HUGE_VMAP
and PMD sized vmap mappings. this patchset is to enable this feature
on arm64/x86.
There are some disadvantages about this feature[2], one of the main
concerns is the possible memory fragmentation/waste in some scenarios,
also archs must ensure that any arch specific vmalloc allocations that
require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
Based on the above considerations, we add the first patch is to let
user to control huge vmalloc mapping default behavior. Meanwhile,
add new kernel parameter hugevmalloc=on/off to enable/disable this
feature at boot time, nohugevmalloc parameter is still supported.
The later two patches to enable this feature on arm64/x86, select
HAVE_ARCH_HUGE_VMALLOC and mark VM_NO_HUGE_VMAP in arch's module_alloc().
This patchset based on next-20211224.
v2:
- Default y for HUGE_VMALLOC_DEFAULT_ENABLED, not only select it on PPC
- Fix copy/type error
- Mark VM_NO_HUGE_VMAP in module_alloc() on arm64/x86
[1] https://lore.kernel.org/linux-mm/20210317062402.533919-1-npiggin@gmail.com/
[2] https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/
Kefeng Wang (3):
mm: vmalloc: Let user to control huge vmalloc default behavior
arm64: Support huge vmalloc mappings
x86: Support huge vmalloc mappings
.../admin-guide/kernel-parameters.txt | 14 +++++++++++++-
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/module.c | 5 +++--
arch/x86/Kconfig | 1 +
arch/x86/kernel/module.c | 4 ++--
mm/Kconfig | 8 ++++++++
mm/vmalloc.c | 18 +++++++++++++++++-
7 files changed, 45 insertions(+), 6 deletions(-)
--
2.26.2
next reply other threads:[~2021-12-27 14:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-27 14:59 Kefeng Wang [this message]
2021-12-27 14:59 ` [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Kefeng Wang
2022-01-18 2:52 ` Nicholas Piggin
2022-01-19 12:57 ` Kefeng Wang
2022-01-19 13:22 ` Matthew Wilcox
2022-01-19 13:44 ` Kefeng Wang
2022-01-19 13:48 ` Matthew Wilcox
2021-12-27 14:59 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Kefeng Wang
2021-12-27 17:35 ` (No subject) William Kucharski
2021-12-28 1:36 ` Kefeng Wang
2022-01-15 10:05 ` [PATCH v2 2/3] arm64: Support huge vmalloc mappings Christophe Leroy
2021-12-27 14:59 ` [PATCH v2 3/3] x86: " Kefeng Wang
2021-12-27 15:56 ` Dave Hansen
2021-12-28 10:26 ` Kefeng Wang
2021-12-28 16:14 ` Dave Hansen
2021-12-29 11:01 ` Kefeng Wang
2022-01-15 10:17 ` Christophe Leroy
2022-01-15 10:15 ` Christophe Leroy
2022-01-18 2:46 ` Nicholas Piggin
2022-01-18 17:28 ` Dave Hansen
2022-01-19 4:17 ` Nicholas Piggin
2022-01-19 13:32 ` Kefeng Wang
2022-01-15 10:11 ` Christophe Leroy
2022-01-15 10:06 ` Christophe Leroy
2022-01-15 10:07 ` [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Christophe Leroy
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=20211227145903.187152-1-wangkefeng.wang@huawei.com \
--to=wangkefeng.wang@huawei.com \
--cc=akpm@linux-foundation.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=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=willy@infradead.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).