From: Qian Cai <cai@lca.pw>
To: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
Cc: linux-mm@kvack.org, mike.kravetz@oracle.com,
linux-kernel@vger.kernel.org, jay.vosburgh@canonical.com,
kernel@gpiccoli.net
Subject: Re: [PATCH V2] hugetlb: Add nohugepages parameter to prevent hugepages creation
Date: Tue, 15 Oct 2019 04:38:33 -0400 [thread overview]
Message-ID: <3340809E-6529-4A14-9D42-B14D7E54A8F3@lca.pw> (raw)
In-Reply-To: <20191015045158.5297-1-gpiccoli@canonical.com>
> On Oct 15, 2019, at 12:52 AM, Guilherme G. Piccoli <gpiccoli@canonical.com> wrote:
>
> Kdump kernels won't benefit from hugepages - in fact it's quite opposite,
> it may be the case hugepages on kdump kernel can lead to OOM if kernel
> gets unable to allocate demanded pages due to the fact the preallocated
> hugepages are consuming a lot of memory.
>
> This patch proposes a new kernel parameter to prevent the creation of
> HugeTLB hugepages - we currently don't have a way to do that. We can
> even have kdump scripts removing the kernel command-line options to
> set hugepages, but it's not straightforward to prevent sysctl/sysfs
> configuration, given it happens in later boot or anytime when the
> system is running.
>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
> ---
> .../admin-guide/kernel-parameters.txt | 4 +++
> fs/hugetlbfs/inode.c | 5 ++--
> include/linux/hugetlb.h | 7 ++++++
> mm/hugetlb.c | 25 +++++++++++++------
> 4 files changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index a84a83f8881e..061bec851114 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2982,6 +2982,10 @@
>
> nohugeiomap [KNL,x86,PPC] Disable kernel huge I/O mappings.
>
> + nohugepages [KNL] Disable HugeTLB hugepages completely, preventing
> + its setting either by kernel parameter or sysfs;
> + useful specially in kdump kernel.
> +
> nosmt [KNL,S390] Disable symmetric multithreading (SMT).
> Equivalent to smt=1.
No, it does make much sense to even mention kdump here at all as a justification. If somebody blindly set sysfs in the kdump kernel, it will be garbage in and garbage out. It is trivial enough to disable it, as it is what have been done in enterprise distros implementation of kdump where it has no such problem for a decade.
prev parent reply other threads:[~2019-10-15 8:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 4:51 Guilherme G. Piccoli
2019-10-15 8:38 ` Qian Cai [this message]
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=3340809E-6529-4A14-9D42-B14D7E54A8F3@lca.pw \
--to=cai@lca.pw \
--cc=gpiccoli@canonical.com \
--cc=jay.vosburgh@canonical.com \
--cc=kernel@gpiccoli.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
/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