From: Dmytro Maluka <dmaluka@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Dmytro Maluka <dmaluka@chromium.org>
Subject: [PATCH] mm/thp: add CONFIG_TRANSPARENT_HUGEPAGE_NEVER option
Date: Mon, 4 Dec 2023 17:32:54 +0100 [thread overview]
Message-ID: <20231204163254.2636289-1-dmaluka@chromium.org> (raw)
Add an option to disable transparent hugepages by default, in line with
the existing transparent_hugepage=never command line setting.
Rationale: khugepaged has its own non-negligible memory cost even if it
is not used by any applications, since it bumps up vm.min_free_kbytes to
its own required minimum in set_recommended_min_free_kbytes(). For
example, on a machine with 4GB RAM, with 3 mm zones and pageblock_order
== MAX_ORDER, starting khugepaged causes vm.min_free_kbytes increase
from 8MB to 132MB.
So if we use THP on machines with e.g. >=8GB of memory for better
performance, but avoid using it on lower-memory machines to avoid its
memory overhead, then for the same reason we also want to avoid even
starting khugepaged on those <8GB machines. So with
CONFIG_TRANSPARENT_HUGEPAGE_NEVER we can use the same kernel image on
both >=8GB and <8GB machines, with THP support enabled but khugepaged
not started by default. The userspace can then decide to enable THP
(i.e. start khugepaged) via sysfs if needed, based on the total amount
of memory.
This could also be achieved with the existing transparent_hugepage=never
setting in the kernel command line instead. But it seems cleaner to
avoid tweaking the command line for such a basic setting.
P.S. I see that CONFIG_TRANSPARENT_HUGEPAGE_NEVER was already proposed
in the past [1] but without an explanation of the purpose.
[1] https://lore.kernel.org/all/202211301651462590168@zte.com.cn/
Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>
---
mm/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/mm/Kconfig b/mm/Kconfig
index 89971a894b60..ec2d5841c9dc 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -859,6 +859,12 @@ choice
madvise(MADV_HUGEPAGE) but it won't risk to increase the
memory footprint of applications without a guaranteed
benefit.
+
+ config TRANSPARENT_HUGEPAGE_NEVER
+ bool "never"
+ help
+ Disabling Transparent Hugepage by default. It can still be
+ enabled at runtime via sysfs.
endchoice
config THP_SWAP
--
2.43.0.rc2.451.g8631bc7472-goog
next reply other threads:[~2023-12-04 16:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 16:32 Dmytro Maluka [this message]
2023-12-04 19:13 ` Andrew Morton
2023-12-04 19:57 ` Dmytro Maluka
2023-12-04 20:15 ` Andrew Morton
2023-12-05 17:05 ` Dmytro Maluka
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=20231204163254.2636289-1-dmaluka@chromium.org \
--to=dmaluka@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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