[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <3340809E-6529-4A14-9D42-B14D7E54A8F3@lca.pw>
Date: Tue, 15 Oct 2019 04:38:33 -0400
From: Qian Cai <cai@....pw>
To: "Guilherme G. Piccoli" <gpiccoli@...onical.com>
Cc: linux-mm@...ck.org, mike.kravetz@...cle.com,
linux-kernel@...r.kernel.org, jay.vosburgh@...onical.com,
kernel@...ccoli.net
Subject: Re: [PATCH V2] hugetlb: Add nohugepages parameter to prevent hugepages creation
> On Oct 15, 2019, at 12:52 AM, Guilherme G. Piccoli <gpiccoli@...onical.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@...onical.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.
Powered by blists - more mailing lists