Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] hugetlb: Add nohugepages parameter to prevent hugepages creation
Date:   Fri, 11 Oct 2019 19:35:57 -0400
Message-Id: <36C2B5DF-7F21-42C6-BA77-6D86EDCB6BB3@lca.pw>
References: <20191011223955.1435-1-gpiccoli@canonical.com>
Cc:     linux-mm@kvack.org, mike.kravetz@oracle.com,
        linux-kernel@vger.kernel.org, jay.vosburgh@canonical.com,
        kernel@gpiccoli.net
In-Reply-To: <20191011223955.1435-1-gpiccoli@canonical.com>
To:     "Guilherme G. Piccoli" <gpiccoli@canonical.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Oct 11, 2019, at 6:40 PM, Guilherme G. Piccoli <gpiccoli@canonical.com>=
 wrote:
>=20
> 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.
>=20
> 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.

Typically, kdump kernel has its own initramfs, and don=E2=80=99t even need t=
o mount a rootfs, so I can=E2=80=99t see how sysfs/sysctl is relevant here.=