Message ID | 20231204163254.2636289-1-dmaluka@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp2881964vqy; Mon, 4 Dec 2023 08:33:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IHaGkdeXAGPhZ+xyksH8QfMI3d1ugkOgyGcUL6ZGk6JtX3bTjm9WtRSVOBajVr7Htj9MzJh X-Received: by 2002:a05:6a20:258a:b0:18f:97c:6153 with SMTP id k10-20020a056a20258a00b0018f097c6153mr6169277pzd.80.1701707601018; Mon, 04 Dec 2023 08:33:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701707601; cv=none; d=google.com; s=arc-20160816; b=pf2NP7vHwcvcMDjChKw8KMUsfVjBW0sMXmmYH2/cGIgGyxcDsdJ9AdeOL0WUKwa4pL +SS13vXJwAZ64WUIH6btmEf9YsIATrDgLPGSz+1dblPYWMXlnoS7Unj2w5PVHjT6SDyE 9tTpIreMOFEXnIawQE4E/mRBwp6r1DjMNoGeEI5eykpbrzHwgcph90uTTZCw3eRXaizp 0nw0yDDVD8qFCx6fZI6lVsVsuYnUFLXsLxSaQP0rhM/7ri6zVp35Irk9ndAhKD2AGUBK ZpVcnAtMPH6krw/3XVrhsH4MDc03HC8Z1tz1l/cSC8IjhPj+/VKV/S0mx7QsSptN3JKW 2Syg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=lFhZWsGjljRXuXWmnaUrVNi01SgHI8BoKOEoL7qVnHM=; fh=mMul1bbjTI15dNfu1J4R7CTWt52UkAf4lYgt1+UzVVs=; b=ifou5h1N1Xnz373b8AWNsAgNYukRO+VeNtpr7W1748TxBVHIe6xCZLtUcDWory5vSB 0b1hDDw0RpiXm7AGP8igZOYH4Y5k6lE2nD1FlWgIJgDfV7Gdz5UuwU9keAUMsuo3L4JW uPh/sEtRjzZNYgJDSkdaZ3jAyXsrKKqK6h4hcWWLaJQ468sBxaaRKTFItYvCxk+k5saQ e3XPzRp3RsnNTcNs8SfwRdYFXyl1rIyrozHeOXTe2TIj5B7gv1S8dH4CmDHpQXc2tJ5O fLi7F2nLlOs6+a+TIzajHvXF1BxLuQmsj+cOuhT0Rh0SU6G4EzJ2zsXL2PZgSmXrLQ3Q /Rhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=GCy15ayn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id 4-20020a630204000000b005c65d99187asi4246925pgc.140.2023.12.04.08.33.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 08:33:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=GCy15ayn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 4A07980AEB11; Mon, 4 Dec 2023 08:33:16 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344760AbjLDQdI (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Mon, 4 Dec 2023 11:33:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234944AbjLDQdG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 4 Dec 2023 11:33:06 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E03B99B for <linux-kernel@vger.kernel.org>; Mon, 4 Dec 2023 08:33:11 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-50be3611794so2952682e87.0 for <linux-kernel@vger.kernel.org>; Mon, 04 Dec 2023 08:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1701707590; x=1702312390; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=lFhZWsGjljRXuXWmnaUrVNi01SgHI8BoKOEoL7qVnHM=; b=GCy15aynLwI4wXSUjUxK92KBjCnLLxjk912+M+iO/dIvG7+SbSWTWxNvWGa3nXiS1b 4TtfTz0SC31Yw0xw8G6GDHVH2UUoFKm8T3Utq9ruz1Bn6QmjLVviYYZDI3LFAK7u9eUf fH8JcgSO5H5ngdubrN8t7huQwHI/Z2HFV58Fw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701707590; x=1702312390; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lFhZWsGjljRXuXWmnaUrVNi01SgHI8BoKOEoL7qVnHM=; b=xSYPFk1m7UaJprnBF0Uh5FKU6idp6X6k1hhAVWAJbaM39Ai6pXtgK2wOc4QVOBO+dT fj9Ra+qIO/FjqWMqwgMb4uN/DinYzRKtv7qvj6PtbWnTm3eGof7263Tb1wU6cx0vG6n6 REayuPxy/lJYwB0kUPNjWsSNMzMyit0AmL4ETIJO6h/5KH5z38UZ3ECReSI80OAVgPRS xRcHzB8BlK+Dgdt94tkGwXx2DZttgGvWRCqixblznepHg6ETHfjOF+VavEb4/kNuuCbU 36+b0zk/hsZgFGQOhzq2ou5WPV/F0PYVMzhgHauZlh6OI3+kDDlXR6C7yhGXfxRxfD4l Hxzg== X-Gm-Message-State: AOJu0YyskEYbBPrc6Fi9jKWuUP1lBUoejqyL9SChDIpa9zQJ1N2bDZh4 DmUQcqkbqO0E/ywtqv+UVt0L/i8W5lMYMlirGDMocg== X-Received: by 2002:ac2:42c2:0:b0:50b:ffb9:be80 with SMTP id n2-20020ac242c2000000b0050bffb9be80mr192530lfl.119.1701707590111; Mon, 04 Dec 2023 08:33:10 -0800 (PST) Received: from dmaluka.semihalf.net ([83.142.187.84]) by smtp.gmail.com with ESMTPSA id c27-20020ac25f7b000000b00507a0098424sm557118lfc.109.2023.12.04.08.33.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 08:33:09 -0800 (PST) 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 Message-ID: <20231204163254.2636289-1-dmaluka@chromium.org> X-Mailer: git-send-email 2.43.0.rc2.451.g8631bc7472-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 04 Dec 2023 08:33:16 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784369749521210517 X-GMAIL-MSGID: 1784369749521210517 |
Series |
mm/thp: add CONFIG_TRANSPARENT_HUGEPAGE_NEVER option
|
|
Commit Message
Dmytro Maluka
Dec. 4, 2023, 4:32 p.m. UTC
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(+)
Comments
On Mon, 4 Dec 2023 17:32:54 +0100 Dmytro Maluka <dmaluka@chromium.org> wrote: > 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. > > ... > > --- 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 s/Disabling/Disable/ > + enabled at runtime via sysfs. > endchoice The patch adds the config option but doesn't use it?
On Mon, Dec 04, 2023 at 11:13:01AM -0800, Andrew Morton wrote: > On Mon, 4 Dec 2023 17:32:54 +0100 Dmytro Maluka <dmaluka@chromium.org> wrote: > > > 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. > > > > ... > > > > --- 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 > > s/Disabling/Disable/ It is in line with the descriptions of TRANSPARENT_HUGEPAGE_ALWAYS and TRANSPARENT_HUGEPAGE_MADVISE: "Enabling Transparent Hugepage ..." > > + enabled at runtime via sysfs. > > endchoice > > The patch adds the config option but doesn't use it? I should have been more precise: it is not a new option but a new choice for CONFIG_TRANSPARENT_HUGEPAGE, in addition to the existing ALWAYS and MADVISE choices. In mm/huge_memory.c in the declaration of the transparent_hugepage_flags variable, if either ALWAYS or MADVISE is chosen, transparent_hugepage_flags is initialized with such a value that makes khugepaged being started by default during bootup. This patch allows enabling CONFIG_TRANSPARENT_HUGEPAGE without setting either ALWAYS or MADVISE, so that transparent_hugepage_flags is initialized with such a value that khugepaged is not started by default.
On Mon, 4 Dec 2023 20:57:33 +0100 Dmytro Maluka <dmaluka@chromium.org> wrote: > On Mon, Dec 04, 2023 at 11:13:01AM -0800, Andrew Morton wrote: > > On Mon, 4 Dec 2023 17:32:54 +0100 Dmytro Maluka <dmaluka@chromium.org> wrote: > > > > > 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. > > > > > > ... > > > > > > --- 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 > > > > s/Disabling/Disable/ > > It is in line with the descriptions of TRANSPARENT_HUGEPAGE_ALWAYS and > TRANSPARENT_HUGEPAGE_MADVISE: "Enabling Transparent Hugepage ..." Those are incorrect also. > > > + enabled at runtime via sysfs. > > > endchoice > > > > The patch adds the config option but doesn't use it? > > I should have been more precise: it is not a new option but a new choice > for CONFIG_TRANSPARENT_HUGEPAGE, in addition to the existing ALWAYS and > MADVISE choices. In mm/huge_memory.c in the declaration of the > transparent_hugepage_flags variable, if either ALWAYS or MADVISE is > chosen, transparent_hugepage_flags is initialized with such a value > that makes khugepaged being started by default during bootup. This patch > allows enabling CONFIG_TRANSPARENT_HUGEPAGE without setting either > ALWAYS or MADVISE, so that transparent_hugepage_flags is initialized > with such a value that khugepaged is not started by default. OK, thanks.
On Mon, Dec 04, 2023 at 12:15:24PM -0800, Andrew Morton wrote: > On Mon, 4 Dec 2023 20:57:33 +0100 Dmytro Maluka <dmaluka@chromium.org> wrote: > > > On Mon, Dec 04, 2023 at 11:13:01AM -0800, Andrew Morton wrote: > > > On Mon, 4 Dec 2023 17:32:54 +0100 Dmytro Maluka <dmaluka@chromium.org> wrote: > > > > > > > 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. > > > > > > > > ... > > > > > > > > --- 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 > > > > > > s/Disabling/Disable/ > > > > It is in line with the descriptions of TRANSPARENT_HUGEPAGE_ALWAYS and > > TRANSPARENT_HUGEPAGE_MADVISE: "Enabling Transparent Hugepage ..." > > Those are incorrect also. Ok, corrected in v2. Also clarified the changelog wrt your 2nd question. > > > > + enabled at runtime via sysfs. > > > > endchoice > > > > > > The patch adds the config option but doesn't use it? > > > > I should have been more precise: it is not a new option but a new choice > > for CONFIG_TRANSPARENT_HUGEPAGE, in addition to the existing ALWAYS and > > MADVISE choices. In mm/huge_memory.c in the declaration of the > > transparent_hugepage_flags variable, if either ALWAYS or MADVISE is > > chosen, transparent_hugepage_flags is initialized with such a value > > that makes khugepaged being started by default during bootup. This patch > > allows enabling CONFIG_TRANSPARENT_HUGEPAGE without setting either > > ALWAYS or MADVISE, so that transparent_hugepage_flags is initialized > > with such a value that khugepaged is not started by default. > > OK, thanks.
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