From patchwork Mon Dec 4 16:32:54 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmytro Maluka X-Patchwork-Id: 13478761 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CA50C4167B for ; Mon, 4 Dec 2023 16:33:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51C7C6B02C9; Mon, 4 Dec 2023 11:33:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CC426B02CD; Mon, 4 Dec 2023 11:33:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3942A6B02CF; Mon, 4 Dec 2023 11:33:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2743D6B02C9 for ; Mon, 4 Dec 2023 11:33:15 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F2B7FA0268 for ; Mon, 4 Dec 2023 16:33:14 +0000 (UTC) X-FDA: 81529680708.26.73CBB0F Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf13.hostedemail.com (Postfix) with ESMTP id 06AA92000D for ; Mon, 4 Dec 2023 16:33:11 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=gC+P3LsZ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of dmaluka@chromium.org designates 209.85.167.48 as permitted sender) smtp.mailfrom=dmaluka@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701707592; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=lFhZWsGjljRXuXWmnaUrVNi01SgHI8BoKOEoL7qVnHM=; b=uTT15WTPdCrVBa/hVkcw2+wOqFcQTademZI/09I/7skkf39NXxPuGj5fkhs6UTcC5BrypQ tx3p2u93dY8XLmyusTtnnQmI0Jra7RJ6NkDNn1Lx1C9+t1w2hqLGqKrK+2Csyu/Vpiap/k saDywmrkDQeXwLDa9KbwvzRPjc5Ue1k= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=gC+P3LsZ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of dmaluka@chromium.org designates 209.85.167.48 as permitted sender) smtp.mailfrom=dmaluka@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701707592; a=rsa-sha256; cv=none; b=ibrPxRpMYu6xn9pDLhIOJ7187KAGnol5RSj90mZ+PwFGMZQ613JEH0KYJuaALc2x8xx1aP tRFKmTO8mgpXD6GZp17MqE+ZOrNI9Gj69miAwQBZwQM4G2CKJt9PsWDXtrJzanLJeKRuvV P0iIDQt5mvYtFq7hePniJNIHJfPNcoQ= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-50bc8a9503fso6215989e87.3 for ; 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=kvack.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=gC+P3LsZo6zC3HCMBlVHHfAVoB6tarMdmAknVFJgjsvknYqZGPaI1326rWwTfoaVWi 64h/y2vOHyc0CH5zVfj+Xv8cBVNmKIWKNFJkceMBoF5A7MLdLXS2kI9zl8Pcb6OC+EfX qXzyfUVt6t2OOqC4019TKH/RU5WkLHywZzRQE= 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=dXf3HCe4JH6F5sKA93o9LYRfemVKyATJMceqMJi65fu6MxEm9Vw8sp7e76YN1XhcAi auSxIZSc1G8j6GgZ57gm6e+NsfAUyS7k9Pif7XekWthF5nKQohzopfMFSSVId20iu/oj NOAi3G6eSayXku3I02lBcET7Ep4YFCpG7Z/3WNkuSy8Tw3H+MUGO7whgweBG9mWjneQ0 ahBok17J6SNuBjHx0UCx3PM6czvLYtqnuRAtZThHdYXUD2uyKQeCnnPqKnbMRWvvkeKl kHzObhGjYg6e5amYUCLEvH+LvgsOOLo/3ZGSHJKyk16zmamqxv6NetbfYeJZ+pVnUhvc i2PQ== X-Gm-Message-State: AOJu0YzCUv4ASrwIjDkEbjeV6xzVwz42vLY0Kd50CoKscSD1eAsDYxaB zpKaKbgcY89Lu/VP9BEuJSFnDQ== X-Google-Smtp-Source: AGHT+IEzscqvonPSYN5fzR00W/YM0kbQcClqgy3YC5nfaM4r56UyO5MKoZDd6gtHz3ghLKHrVeeAGw== 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 To: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Dmytro Maluka 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 X-Rspamd-Queue-Id: 06AA92000D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 4qm8bax44t8e1x63omgi7z56prns3ayz X-HE-Tag: 1701707591-947502 X-HE-Meta: U2FsdGVkX1+auAKDbQx21kiQ+5Pxe/Avt//A7uohHm6tVqFV6AsCabjFDkq2Y1osptau1+Cd4LXXscntNGwDAQ66Ae5QwAFrR5NKyKVzTnwsi6Bzi2yyw3NOxGEOqdOqFC0yjK6uvsgaNe2cR32PzoKXN6lNtpsODqtaXeXdXyOr/L5LmLdKraElMoBMTcTU7NYDe6ZPAYeDs0czzgzaaTM23mQJQHMDOp8B1a7eWP3F6pkf/IdPOyIx1VYrvMH6WVUIMLVelb+Dv7uxJhvOb/GmNrQJu+LLf3kgE8XpPfF94ml5mw+q0tjGgQ9kP84tjgBkWa+fcDbusgr6+Rfji52QggIFoxQvSnZX//alOKQhCbgb/XlU6t+9makk/GeFGaiKfCD11YGXVkbPf4P9Rsz62BAy+6sr14t3USDlDYtpWMe/uVCt/X1DLNzzmJEKce45QPU5pffnxvuHrk5MfCpHATaKll+ajSLoNuK6WRTFD3xv2SR8UGTyE2/vWQK3UtRNv/fdgGevtm4NQaNOXNZkaZfDWb8Qy4KcRBBjkIwvXKcZOMW2mFb0oZ6e4ZZHtct6raK/cQpzins3N0Nf9kTZ8DOeaSLFkJwKYCmVmLRFGH2K6bkK8Mx5Ipsu4JD95sSE//GxjYsDKh+qBlu9wYU0kwnPadMvZe4I8Im+RdKPVdwsYHZT0d8eA61Sv/U8+eys7GvqtrBuLmH4y4PRcwgNqJa4guFmvbXjD/StxwqzoMjGyvWF7cO2poCQfrc5nPdpEHMKJV2T2dkPl2kA0gi5SmhpF5JUoRr/BYQT/zbwBYeNop3YWmtz0/LQpeAfqCIvOWLRPoJ4UEcLgkTBptIC/b1LugKeLtL/o+VCeHEBLM1KtVju1LlXmHly8gK94snmBFuA098CbRMabcdXFYG0cASN4F+3ugbP31hsvSWhkvwc+aGt+AUtVBlj1wlI2w59pIgbQaHPvGMW7FK +O50JTbp In8Sv80Ygs2mSqGP41Hu6xULQ+kNL5W0DMWfO9vXxpOpXd/nwT/HugP1wpg/J9lt/+Vc90Il6JpGxuFRThPx4T4HcHGvPN/H9G5gMribZlYYvz4jg+G7c2tPgoZxvAg9Lh1rVMqvJa3FJ8tk8Uvkw1LaM3Al6aEhkAvyhf75vL1b+O9KJrQ0iyLZBdUJ3ujAU0SSayqgpv3WhzXKiM+LsSBi10Fn13xh06tiw0GRm1S3Ta2ZtzomKMYE4XuLxvtekA+q4Ps2IAQ7zhORuKU51gyzsWBD7428BAvq3AbXCRpNSstSMwB0jltAVA54wTJ9qLE/CHnwKEoCw/vf+OswY8EBBpvtxgxIk6brih0Cq3o+yN7JqTe7C2IYxCepsCPvdjMmOWj6ectgTGAGW1R8e/tE6fSwrfVVrQHbrOOI+gcChqyTOqcQOqnc3+MJzpdH7iyy2ZU8wIANhBlXKRG8QwJF4/0YGpVbeuHe7loXF4mlz/RNnhPyF4c/rNJgApslRZqfQNOqhHbsocCvZhkziRNWu42VgqsrozDPM+6iaLMnGzQd8M2ACAs0BrQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 --- 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