Message ID | 20231205170244.2746210-1-dmaluka@chromium.org (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 7D826C10DCE for <linux-mm@archiver.kernel.org>; Tue, 5 Dec 2023 17:03:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3BAE6B0095; Tue, 5 Dec 2023 12:03:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEB936B0096; Tue, 5 Dec 2023 12:03:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8E1F6B0098; Tue, 5 Dec 2023 12:03:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C5EFB6B0095 for <linux-mm@kvack.org>; Tue, 5 Dec 2023 12:03:25 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9D3081A01EF for <linux-mm@kvack.org>; Tue, 5 Dec 2023 17:03:25 +0000 (UTC) X-FDA: 81533385570.23.1AA4A87 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf14.hostedemail.com (Postfix) with ESMTP id EAEDC10003C for <linux-mm@kvack.org>; Tue, 5 Dec 2023 17:02:51 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HUeSGubE; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of dmaluka@chromium.org designates 209.85.218.44 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=1701795772; 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=kBCPsrxEK/c4yfZsrOW2rPVQB4Gl/XCShj5B3/oom0w=; b=7rvzxZcRZyzhBaOnMdz2k4qD1N6G1LEMsM9tnnH5IOCcF7H5jc3UnQBbcZLWkylCIT4Upd eMOUSqcmsYBbN95/HWhVwP2PZW9gU9P0sDaQ3wVwqJ8Nd6SkVtJ5oDTFBJNHNaTNqa6WMa Yt7jTvXf89J/Udmo0za4ZSc2iMozKgY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HUeSGubE; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of dmaluka@chromium.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=dmaluka@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701795772; a=rsa-sha256; cv=none; b=1Msb9qrDj/ZoDjLWtihA4lQuGhFmGlyYKtttcsjL7DpaAm8SyrcBDecjVOiPqaDQ8pg/+L IjjL5jm0lNH0/ARiJ2LM9dWmKOHTm4MMc/fm3IAACnp/7KpcVa4CenITQIPLQlLdALvIVK m/7dFxMfMtBd6mtFkQCjgnfnA2Z2FtI= Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a06e59384b6so807062066b.1 for <linux-mm@kvack.org>; Tue, 05 Dec 2023 09:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1701795770; x=1702400570; 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=kBCPsrxEK/c4yfZsrOW2rPVQB4Gl/XCShj5B3/oom0w=; b=HUeSGubE9Iwwg5abDlIfUSa8LlKRHXJxBa8HC6MabqjqEiQW8v28spKYG5ikINQWTw 4g5qNxpX8YPk0nC8PgSlDGBV/1Ur7N4cusMWCmyR69cIXKIFx5Dye2xaPzY69FtqCRDJ Ni4c7bi7xWNm2z6aZCGl9eRr/5MLDHfS9B1YA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701795770; x=1702400570; 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=kBCPsrxEK/c4yfZsrOW2rPVQB4Gl/XCShj5B3/oom0w=; b=uVjSn4p9t05viJvcW4gaUrrezVrn7Ar1xAmW1p8Ox/GJH8/5FF1RKTIUUZFJmzirdG osCeK92FHmjmPurpeBcB/VsfZGbRxI036/KrMdMnAfWYVKFVSSK/iN9xivlyxZBIvvbY XkBlpeZPIWHw77G4oquwv+lUYbqpNfHZR6y0+vFeaqDSN7mXT22WLj8Gei/ISZN85Bmv bFoyAUX0Tor4PFcR+t4RJng/Fi1h4HZJ86QUwsmSKfA9tK/dw7S4tdKPlhQYDAr/TUJu /sSxpl798Cr6x/A+OxqPEhhiXV3pN2whAjD0iLSPqw6QyWKzcNY7WsIGxhT+BTFbOK4m jcEQ== X-Gm-Message-State: AOJu0Yxukrpb9ojgUsQ2TVOL/AP9SwTdTIYWQIF3XGO1iKxcq9/CsFWO KKz7LIcnFIXzj8AfbifmQUv+zQ== X-Google-Smtp-Source: AGHT+IF6pfu03qpQiFZ3BlrYh/Quz8jSlWuW9+HAm2uQIiOgN9orMb3UfN2bEmGq1S95ehwpvEzeMg== X-Received: by 2002:a17:906:739c:b0:a1b:86e5:4e1 with SMTP id f28-20020a170906739c00b00a1b86e504e1mr1744817ejl.108.1701795769422; Tue, 05 Dec 2023 09:02:49 -0800 (PST) Received: from dmaluka.semihalf.net ([83.142.187.84]) by smtp.gmail.com with ESMTPSA id uz14-20020a170907118e00b00a0104d5758dsm6932354ejb.50.2023.12.05.09.02.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 09:02:49 -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 v2] mm/thp: add CONFIG_TRANSPARENT_HUGEPAGE_NEVER option Date: Tue, 5 Dec 2023 18:02:44 +0100 Message-ID: <20231205170244.2746210-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-Rspamd-Queue-Id: EAEDC10003C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ttswrqkky43zywu1egf7ypkudk39iqsz X-HE-Tag: 1701795771-26489 X-HE-Meta: U2FsdGVkX19A+bH2nZTknss7SIN7TCCgDG6zsOj4QlXMM/cjFijYsFXyhlEHlq8yWUSybOtT3V5gI4iYk5TZuz39dgQbd+SjYLq6e2Mk8LPsepCHoRMUoThyntNf3kvHjFxRDt/t8VXVa1eXCryKApPGhUhSNtPKNgR6+3l0nHqBHQtxfEbbYXNK6SR0wKw6tYmkhzyG1iPDojGcvFWYBQ/WgJvoee45sjyNr+kAoQKV69BsAGX3UFLrbCxx8RAgF02D9J5CX9803oqTUURxe/bxYAIPS8OILdJ98JkQPgXYOpvIbKOg94SRLOrbTzaW25m34dGEN8yUf2Nr/4ktmQcDQP4zfrEwPLOTH7JT4y/DVsUmeJGtvXaTQhCJwhW1fhbhvTokibqNo1zgnQWFJI0oEzqmRmAKKAGTvO0p1XLHZ7J7/rJaIVUD7tUh61MfSZ+B+r7cBHOR1Abd2fqvf+0AfMnH23HZZgTampjWMW/NYuOe5Wefs1A44Ht7FGZQAnW8aMn5I/3TCQUO5b+DWIyaOm3qU3FRjYUkDaXUiloQWruRrlacKYyM/tt6vTNMEtpCQMpb5NBoOhGyLPJ1C4x0w9e08sTVC8I/kyGTXq7a45QkaSsoubqjp2buuytmGUTbeDFQLy8axoNGKvIW9BeayGK3jxueV+f37qz1f3LJ0d0RrxbHl+0Ifds9SBRWaP+BTj6Sj6bIdkZqmXDethPUmexmXxN9C/BK/VRcX9MVM5+CX+hHcPFXn1aopNSoCZBB6Lg2R/KdKQVmJF6rw315pCfC5+CgcvzJO8ZUwPSKPjhR+rqGYbNdlowLsXrAeSBRHCW+A0G9WY/ALs+SFKF+fmchHNB/WPLDKmDibkgErPdTbzfHUR4JHa9iKq4IoAwo8u/CeSRAyRMZScrX9tvdit6eh8u5J40l6uD6Svows/7QIlcJb96SjCaI3eI294wmvLby+9mi07s6PTG exJHRtK2 HFqUCZ5W8NehNJ8Vx6sIFZ7uzfuCbmuIG8rUNAZH/pm89+u8rpqRa82O/201ViYpGmZ6id+dtMXzJC+wPNhL52qAIJOBIwoxEs9Efz5mrPQ34rz/hy8rDcabHsY9cQ3WT5d6J8SO7Y0nwIQRG5pe9tDdIHPXSrN18ozN+ERCBhoqyAFTZvVEWzfzlD1s/oc0CbFoxZC3OJ2s+LP6cWo0ohXqT+KmknOlmIjqqwqoXaQSPHd+TEbOqGIE33P2mNu070Ji+UrRupJlaFQob3F36DjPRe7J71YXJsg9fXKMI7hzERUs7UUBwwYVbGEvVO+6d4OOZty4kT3PKgyNH3Ik2XYLrEVhf+hjMg27sYglADmQ4msV81Z+XFxoJQIScTWCGqNtoCYANN9bEoiUi0g/fji7tee+9OXepqw0eEe9d2uZ9szaOyB3tZ76xPDzYqrN1WbwnFMJ1ZQCqaNJoIqNFM/Qdu1gOF18MlB81Iv6OcsODuvuuVBEf5J5FuHtO9VvYxWUp3LRf9e0GKyH5IOZo8QUc9ghCplUwl0XEGznUFEFHx75bbIyA/ME2/A== 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
[v2] mm/thp: add CONFIG_TRANSPARENT_HUGEPAGE_NEVER option
|
expand
|
diff --git a/mm/Kconfig b/mm/Kconfig index 89971a894b60..1930e18be8a1 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 + Disable Transparent Hugepage by default. It can still be + enabled at runtime via sysfs. endchoice config THP_SWAP
Currently enabling THP support (CONFIG_TRANSPARENT_HUGEPAGE) requires enabling either CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS or CONFIG_TRANSPARENT_HUGEPAGE_MADVISE, which both cause khugepaged starting by default at kernel bootup. Add the third choice CONFIG_TRANSPARENT_HUGEPAGE_NEVER, in line with the existing kernel command line setting transparent_hugepage=never, to disable THP by default (in particular, to prevent starting khugepaged by default) but still allow enabling it at runtime via sysfs. 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 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> Link: https://lore.kernel.org/all/20231204163254.2636289-1-dmaluka@chromium.org/ --- v1 -> v2: Cosmetic documentation changes: - s/Disabling/Disable/ per Andrew - Clarified in the changelog that this adds a new choice "never" in addition to "always" and "madvise" --- mm/Kconfig | 6 ++++++ 1 file changed, 6 insertions(+)