From mboxrd@z Thu Jan 1 00:00:00 1970 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 AB2A8C369C2 for ; Fri, 18 Apr 2025 01:02:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E56E2800C8; Thu, 17 Apr 2025 21:02:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2945C2800C6; Thu, 17 Apr 2025 21:02:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 185172800C8; Thu, 17 Apr 2025 21:02:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F0AF42800C6 for ; Thu, 17 Apr 2025 21:02:45 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5E7DBB3036 for ; Fri, 18 Apr 2025 01:02:46 +0000 (UTC) X-FDA: 83345364732.13.C01C8E3 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf05.hostedemail.com (Postfix) with ESMTP id 7592B100004 for ; Fri, 18 Apr 2025 01:02:44 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VNJpU8nk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744938164; a=rsa-sha256; cv=none; b=N2nHWzvHwMxOOcrG38n1Ut3uWW02N3bkeM/gDl0j/eN8mO0uJlMYmJ6/5BlNWq4e06Unnp ogE4cGT5p6DkjGY1zczPC+xr3xzmWUx0mkZuQSYWTYwCn+A3eaJpKb/zSU67OHoBcKL6n+ 47vMJfRTe2w00biLVAyMeZ0YNXeOiU8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VNJpU8nk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of bagasdotme@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=bagasdotme@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744938164; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6NXDfDK3aSml2E+saDauRdMH/9W2bC9OP7905GHXeqg=; b=Y9UL9Tn34PJ0+vEkpRzzyD7bBaRR2z0Qim2P3IEUWEck9xBpq491Dx0iorwdTU6aiyKbjH LgvMPe3aiBDUS9Y7tBdUlvyNk0l1s2naRg4zACeK6YKyOno1jkHeQG6PlzuFtQpg1VVfiI 7R3TWxzauSke5GSRfFyi5riKJPMVFCY= Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2279915e06eso16921695ad.1 for ; Thu, 17 Apr 2025 18:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744938163; x=1745542963; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=6NXDfDK3aSml2E+saDauRdMH/9W2bC9OP7905GHXeqg=; b=VNJpU8nkTNXSiHsJBkgMjcx4U6jMi1aUCVB0Z7iW7+LQRAMo6cQJcncdTtstysSvZK /YTYxVtzPNRwpXIIl443cyUD15gpDKTIzBWW/TkAJkGGhbKCfgCKTY5TRHyVezxrMOcc UnoD9VzRilFxjK5EP2PlUJfKlyMoIV5wwva9S3p5am1Z2+uqgoAkx44ruJJmpePCzePW xtzLrQcvpONWpOVWVEBqvkYkkZRokHYWFT1+jWI2WuciVsISZM3XYw6mgN1/cciUuAg8 7H5l4j63ds2KDkUxzp5Kgm9sAAFC0qmHbxzf+U2hzyEu4+Go+mr/s7ESoquqI2yqOOL4 U5Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744938163; x=1745542963; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6NXDfDK3aSml2E+saDauRdMH/9W2bC9OP7905GHXeqg=; b=Oc062OSlvRIY7rKtfyLwBkMlmuVS1vZPzaBugZRrvROyiF2UtWWXZ3jKlJQrCM60L+ Q9RsgpIhiehXq0J3bXdwxrl2RCiflgVj8aBbMa0eV+InQKNE+anBI2fDB2XtjIk/rYLH 1iBQfMyy3ILLkfp1NzJ/s41oz3txzb2LTjc7mFFEW6x4//f0VYh2x5O/S9G4VE5QzKWM 2xSAzBqWQesZ0b/oLzOGt+GTPVL7Ph7w+mhEODS/1qOfJt6aUcl2Lt78Hc06G9OLBosq +lZSLqnoxjI5TwU40WNsCbLEShUoHD2YpddNy7w5k8aoVZXKH1mj5KaJI4RMjJZ8zVyW k9Ww== X-Forwarded-Encrypted: i=1; AJvYcCWlMHGWOKte1yrHS8l6/gAAc50WxbW+I0/SzeQlQ2QrP+vMg8p5qfFAvBckZnJREj8QD8DTxchm8w==@kvack.org X-Gm-Message-State: AOJu0YzWukOQEpXWESAnKQOZd+zesKU2lSXorVb5j1EAZDLtLJKNsa5O DFFtddzGhXFfuZNmXe9qe3/p2KN6f2pukd+ADxP7FaR2Ykib5qiH X-Gm-Gg: ASbGncvIH8pIht95XDcdrntsik3a819JUUyDNOL3bKjakCiigqCll7l7y989BXRAILj XyYvgPZj8CVli3x6oCrMhcfnUC1T7Laxx5lq05e2bYRC2c6HRdAmmcQvXS49O1lfrX62U69lWX0 6nFfww+qGROJfhjqxe1i8fkpqw19paC6s/s2DIs9yTIOeYJ4nkE/WxG7NNGXS/2c5cNjW1jFI6s cvGru4bljsbIjdwqTTQ5WUGTaBarnENdWQmZQq1cLZzWFdrMcng1fH9YAkNcAZunS/YDsOcRAb1 +spkYutiHmU3cWyPmH/09apa+MQUBm+4d4NtleuI X-Google-Smtp-Source: AGHT+IHDm2/uiDHbeptzLGovtbbE44rhzmmK5eRP8BwU9MWedsOqamPglnynKile7HYwKCMMQ1kxTA== X-Received: by 2002:a17:902:d589:b0:224:1157:6d26 with SMTP id d9443c01a7336-22c53573b4amr15702485ad.4.1744938163034; Thu, 17 Apr 2025 18:02:43 -0700 (PDT) Received: from archie.me ([103.124.138.155]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73dbf8e4912sm550714b3a.60.2025.04.17.18.02.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Apr 2025 18:02:41 -0700 (PDT) Received: by archie.me (Postfix, from userid 1000) id 3238A4209E46; Fri, 18 Apr 2025 08:02:39 +0700 (WIB) Date: Fri, 18 Apr 2025 08:02:39 +0700 From: Bagas Sanjaya To: Nico Pache , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: akpm@linux-foundation.org, corbet@lwn.net, rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, david@redhat.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, ryan.roberts@arm.com, willy@infradead.org, peterx@redhat.com, shuah@kernel.org, ziy@nvidia.com, wangkefeng.wang@huawei.com, usamaarif642@gmail.com, sunnanyong@huawei.com, vishal.moola@gmail.com, thomas.hellstrom@linux.intel.com, yang@os.amperecomputing.com, kirill.shutemov@linux.intel.com, aarcange@redhat.com, raquini@redhat.com, dev.jain@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, tiwai@suse.de, will@kernel.org, dave.hansen@linux.intel.com, jack@suse.cz, cl@gentwo.org, jglisse@google.com, surenb@google.com, zokeefe@google.com, hannes@cmpxchg.org, rientjes@google.com, mhocko@suse.com, rdunlap@infradead.org Subject: Re: [PATCH v4 2/4] mm: document (m)THP defer usage Message-ID: References: <20250417001846.81480-1-npache@redhat.com> <20250417001846.81480-3-npache@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KNDrqzrcH5sLMMxx" Content-Disposition: inline In-Reply-To: <20250417001846.81480-3-npache@redhat.com> X-Rspamd-Queue-Id: 7592B100004 X-Stat-Signature: 8ypt5jzshixw5u6e8qjio7fmrmtxaisd X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1744938164-474852 X-HE-Meta: U2FsdGVkX19e4FZNeh4dSs34Vyz1flRjkSQ24HoLWMyVYZpJmwhVpCXIyGTRoRG1xfbACQHqqAPeKl36DDD9DaV9C7jhFWjnvywRANenCdHr3chNwkc8wptxPzWs6vgmr7aILH/X56DH+WEDCvPyawkG8huE/E3GcPAikZ33LTSo28xje1eAvOdWWNS4sKyAUEM+u1bW3eHMIdNhQWB3cty8JF6ZUfMcWjwcQxqYBomS8YzcP3ZVVikZH1HfULF1K0kd+6O5DnreIQMQ/muwU5ci12atDJE/hjkQXK0lG4HOLfUv17yqmlCdLM1RUUQvXINJ4GhjORmx+IW4mVEAtKTZ5+4PmG/IxKXaHiRbiPQ52h1+TdAYMHNKu8oTJfDKkE5Y/UAlJVsHxreWRtAKl5KEG3G2AzZvtddVWS7+eKjNNDY7yj9LiDoivSq3uszQ93TqjNV5HIExXblm6Bl7XWSmco+zAYiJoLpJWI3OGYewgFmzOifM0T9QAMnjkH34fWPaf5JfUjOlVgCoZVZz5p9VH0HTFMosPcyVFTnYm8/BN6sOOJibUgnswJrVcimA7002JkDHOJCyBxpB4aJ8JPCytpgMyVMeCjK7cmK50BeEMosEclf/XW6KM05Mg/BRYwj+8vKXvarlwjmAyHwn9YXMDHPhzFWbvQOQ+fmq4sSbBwFyBLUWYd7LXjT4oPaCAAVNcgDZAXWsOXbE8ZP5aTkxWs9OIOdidaDaQgXvIaQhXH7oQ2lqz1l/RL3MokyPZJNO8HXAQgwsGrRIDG+MKdFd+0fwF16a/lSruB9jhsTzMnCDZHd4YBiW0dYt+ArJc/BltNvg7NodthX4AHipaNi6/gnOnhcUo2NXjvpmMmhVY6rv0orRQe6AfBefPh2QHMicE0tRRDXxOTMakO7W31+If9eUvHyCJ2pGcsUmoZUYcvSGbvd4KFyS1mDBUaBgDbYZJLvOd4U6RjJz8RF USdA0Njl htDMuZwMy49R/5u9nkpza4wzdbJtRaQaknr/1tyWU5sn49rQQs+u5ZG2JiuNnOEDxgynMuX3pg0BBUqa6ivYbEaZxd4XEqgrQ+mQHAyX0JpcHIpA+LFkVdUpTZ8wxooY0PTIPtR+fVx1V8HPdmx1H6jtLuVe4tSoaGOfl3uF4jp/6oCuuLmKMMGjvfDcKliuOjV3oQ4fDwPAtg2FKAzjtCqCc9BJCnOMKOhbeKFxDK2uLOAFZwQMJsmzA8ea9RM+ZcIZnjYOLoQbw3A7AMyD5IUuaLK/uqKcuRkrL3ETmVMh6OqZMpGbBPyADA+aQyTePf5+yj4aIciYbx8J5Zzb0ou77YPtH6tjDjj0I4PoPUbTP3CigXXNIn0+QggO8m3VQZach6AaP/6ob/UGCLLvszoiD6Cn12t4ZVS9++s8KMl80S5e5AWgYGIBmJ7KGFdw6gqbybeX/iTDlz0r6fb1rbD9027yPoMp95wOVRO3irs30kBBgXilZMJtu6B9Xbmj0huQLQXKX1IZPU8/WeSVj+rCX8UGqi/wO6+kGeftsXMDDdp0= 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: --KNDrqzrcH5sLMMxx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2025 at 06:18:44PM -0600, Nico Pache wrote: > diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/a= dmin-guide/mm/transhuge.rst > index 06814e05e1d5..38e1778d9eaa 100644 > --- a/Documentation/admin-guide/mm/transhuge.rst > +++ b/Documentation/admin-guide/mm/transhuge.rst > @@ -88,8 +88,9 @@ In certain cases when hugepages are enabled system wide= , application > may end up allocating more memory resources. An application may mmap a > large region but only touch 1 byte of it, in that case a 2M page might > be allocated instead of a 4k page for no good. This is why it's > -possible to disable hugepages system-wide and to only have them inside > -MADV_HUGEPAGE madvise regions. > +possible to disable hugepages system-wide, only have them inside > +MADV_HUGEPAGE madvise regions, or defer them away from the page fault > +handler to khugepaged. > =20 > Embedded systems should enable hugepages only inside madvise regions > to eliminate any risk of wasting any precious byte of memory and to > @@ -99,6 +100,15 @@ Applications that gets a lot of benefit from hugepage= s and that don't > risk to lose memory by using hugepages, should use > madvise(MADV_HUGEPAGE) on their critical mmapped regions. > =20 > +Applications that would like to benefit from THPs but would still like a > +more memory conservative approach can choose 'defer'. This avoids > +inserting THPs at the page fault handler unless they are MADV_HUGEPAGE. > +Khugepaged will then scan the mappings for potential collapses into (m)T= HP > +pages. Admins using this the 'defer' setting should consider > +tweaking khugepaged/max_ptes_none. The current default of 511 may > +aggressively collapse your PTEs into PMDs. Lower this value to conserve > +more memory (i.e., max_ptes_none=3D64). > + > .. _thp_sysfs: > =20 > sysfs > @@ -109,11 +119,14 @@ Global THP controls > =20 > Transparent Hugepage Support for anonymous memory can be entirely disabl= ed > (mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE > -regions (to avoid the risk of consuming more memory resources) or enabled > -system wide. This can be achieved per-supported-THP-size with one of:: > +regions (to avoid the risk of consuming more memory resources), deferred= to > +khugepaged, or enabled system wide. > + > +This can be achieved per-supported-THP-size with one of:: > =20 > echo always >/sys/kernel/mm/transparent_hugepage/hugepages-kB/ena= bled > echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-kB/en= abled > + echo defer >/sys/kernel/mm/transparent_hugepage/hugepages-kB/enab= led > echo never >/sys/kernel/mm/transparent_hugepage/hugepages-kB/enab= led > =20 > where is the hugepage size being addressed, the available sizes > @@ -136,6 +149,7 @@ The top-level setting (for use with "inherit") can be= set by issuing > one of the following commands:: > =20 > echo always >/sys/kernel/mm/transparent_hugepage/enabled > + echo defer >/sys/kernel/mm/transparent_hugepage/enabled > echo madvise >/sys/kernel/mm/transparent_hugepage/enabled > echo never >/sys/kernel/mm/transparent_hugepage/enabled > =20 > @@ -282,7 +296,8 @@ of small pages into one large page:: > A higher value leads to use additional memory for programs. > A lower value leads to gain less thp performance. Value of > max_ptes_none can waste cpu time very little, you can > -ignore it. > +ignore it. Consider lowering this value when using > +``transparent_hugepage=3Ddefer`` > =20 > ``max_ptes_swap`` specifies how many pages can be brought in from > swap when collapsing a group of pages into a transparent huge page:: > @@ -307,14 +322,14 @@ Boot parameters > =20 > You can change the sysfs boot time default for the top-level "enabled" > control by passing the parameter ``transparent_hugepage=3Dalways`` or > -``transparent_hugepage=3Dmadvise`` or ``transparent_hugepage=3Dnever`` t= o the > -kernel command line. > +``transparent_hugepage=3Dmadvise`` or ``transparent_hugepage=3Ddefer`` or > +``transparent_hugepage=3Dnever`` to the kernel command line. > =20 > Alternatively, each supported anonymous THP size can be controlled by > passing ``thp_anon=3D[KMG],[KMG]:;[KMG]-[= KMG]:``, > where ```` is the THP size (must be a power of 2 of PAGE_SIZE and > supported anonymous THP) and ```` is one of ``always``, ``madvis= e``, > -``never`` or ``inherit``. > +``defer``, ``never`` or ``inherit``. > =20 > For example, the following will set 16K, 32K, 64K THP to ``always``, > set 128K, 512K to ``inherit``, set 256K to ``madvise`` and 1M, 2M Looks good, thanks! Reviewed-by: Bagas Sanjaya --=20 An old man doll... just what I always wanted! - Clara --KNDrqzrcH5sLMMxx Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCaAGkqwAKCRD2uYlJVVFO o76GAP4gVe3Gv1BdLnJiW4rDIJQ6VD6/W+Sr//civHKYU9VsUQEAuc1azxqwsSEj K00HI9k41AAjpL6TTipYDczBL0F01w4= =KYIn -----END PGP SIGNATURE----- --KNDrqzrcH5sLMMxx--