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 5B386C54748 for ; Wed, 28 Aug 2024 01:19:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D17266B0083; Tue, 27 Aug 2024 21:19:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC70D6B0088; Tue, 27 Aug 2024 21:19:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8F136B0089; Tue, 27 Aug 2024 21:19:25 -0400 (EDT) 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 9AF306B0083 for ; Tue, 27 Aug 2024 21:19:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 482A9C1B2D for ; Wed, 28 Aug 2024 01:19:25 +0000 (UTC) X-FDA: 82499896290.03.F78F2A5 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf14.hostedemail.com (Postfix) with ESMTP id 993D3100004 for ; Wed, 28 Aug 2024 01:19:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724807893; h=from:from:sender: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ms90ZfuGTSmYoDdlexybq2TrNT+dwIexRy+xuIKnH08=; b=IVa5U5Z2izjFWdXFrZnqKCFyN3Ixf0ROVMXsYq9cSoQC/PhVHk0nfXaoHRStNFIi310Prd yQZlHAtUw/MrmF40FxFSXu/A4k9O5Kt9f8MtZSZDPOyjs090wVya5/rP0VY6g0VntvGewX zDdw9YXD3+whH38MWgHesJzlvtl4BLs= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724807893; a=rsa-sha256; cv=none; b=0Q0gEhvDpRVN8rHvI+RKR2c4UtzwRTvQUHQWH3m4h95E0h/aa8XrZv7A1Be+jPWqhiTtpc sSK9I6+GYSjpp6pqVSe/yLfe5CBybxBeIORbHUTgFeJbDfGpSR57/ARVURvni6NbuVmbBC O0NlKpNumLpLRuBLNr1aRyKD0M3uw8c= Received: from [2601:18c:9101:a8b6:6e0b:84ff:fee2:98bb] (helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1sj7Ks-000000003Zt-3y7g; Tue, 27 Aug 2024 21:18:58 -0400 Message-ID: <9cf237df1a7bb21bba1a464787938eba8f372658.camel@surriel.com> Subject: Re: [RFC 0/2] mm: introduce THP deferred setting From: Rik van Riel To: Johannes Weiner , Usama Arif Cc: Nico Pache , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Andrew Morton , David Hildenbrand , Matthew Wilcox , Barry Song , Ryan Roberts , Baolin Wang , Lance Yang , Peter Xu , Rafael Aquini , Andrea Arcangeli , Jonathan Corbet , "Kirill A . Shutemov" , Zi Yan Date: Tue, 27 Aug 2024 21:18:58 -0400 In-Reply-To: <20240827110959.GA438928@cmpxchg.org> References: <20240729222727.64319-1-npache@redhat.com> <72320F9D-9B6A-4ABA-9B18-E59B8382A262@nvidia.com> <61411216-d196-42de-aa64-12bd28aef44f@gmail.com> <698ea52e-db99-4d21-9984-ad07038d4068@gmail.com> <20240827110959.GA438928@cmpxchg.org> Autocrypt: addr=riel@surriel.com; prefer-encrypt=mutual; keydata=mQENBFIt3aUBCADCK0LicyCYyMa0E1lodCDUBf6G+6C5UXKG1jEYwQu49cc/gUBTTk33Aeo2hjn4JinVaPF3zfZprnKMEGGv4dHvEOCPWiNhlz5RtqH3SKJllq2dpeMS9RqbMvDA36rlJIIo47Z/nl6IA8MDhSqyqdnTY8z7LnQHqq16jAqwo7Ll9qALXz4yG1ZdSCmo80VPetBZZPw7WMjo+1hByv/lvdFnLfiQ52tayuuC1r9x2qZ/SYWd2M4p/f5CLmvG9UcnkbYFsKWz8bwOBWKg1PQcaYHLx06sHGdYdIDaeVvkIfMFwAprSo5EFU+aes2VB2ZjugOTbkkW2aPSWTRsBhPHhV6dABEBAAG0HlJpayB2YW4gUmllbCA8cmllbEByZWRoYXQuY29tPokBHwQwAQIACQUCW5LcVgIdIAAKCRDOed6ShMTeg05SB/986ogEgdq4byrtaBQKFg5LWfd8e+h+QzLOg/T8mSS3dJzFXe5JBOfvYg7Bj47xXi9I5sM+I9Lu9+1XVb/r2rGJrU1DwA09TnmyFtK76bgMF0sBEh1ECILYNQTEIemzNFwOWLZZlEhZFRJsZyX+mtEp/WQIygHVWjwuP69VJw+fPQvLOGn4j8W9QXuvhha7u1QJ7mYx4dLGHrZlHdwDsqpvWsW+3rsIqs1BBe5/Itz9o6y9gLNtQzwmSDioV8KhF85VmYInslhv5tUtMEppfdTLyX4SUKh8ftNIVmH9mXyRCZclSoa6IMd635Jq1Pj2/Lp64tOzSvN5Y9zaiCc5FucXtB9SaWsgdmFuIFJpZWwgPHJpZWxAc3VycmllbC5jb20+iQE+BBMBAgAoBQJSLd2lAhsjBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDOed6ShMTeg4PpB/0ZivKYFt0LaB22ssWUrBoeNWCP1NY/lkq2QbPhR3agLB7ZXI97PF2z/5QD9 Fuy/FD/j ddPxKRTvFCtHcEzTOcFjBmf52uqgt3U40H9GM++0IM0yHusd9EzlaWsbp09vsAV2DwdqS69x9RPbvE/NefO5subhocH76okcF/aQiQ+oj2j6LJZGBJBVigOHg+4zyzdDgKM+jp0bvDI51KQ4XfxV593OhvkS3z3FPx0CE7l62WhWrieHyBblqvkTYgJ6dq4bsYpqxxGJOkQ47WpEUx6onH+rImWmPJbSYGhwBzTo0MmG1Nb1qGPG+mTrSmJjDRxrwf1zjmYqQreWVSFEt26tBpSaWsgdmFuIFJpZWwgPHJpZWxAZmIuY29tPokBPgQTAQIAKAUCW5LbiAIbIwUJEswDAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQznnekoTE3oOUEQgAsrGxjTC1bGtZyuvyQPcXclap11Ogib6rQywGYu6/Mnkbd6hbyY3wpdyQii/cas2S44NcQj8HkGv91JLVE24/Wt0gITPCH3rLVJJDGQxprHTVDs1t1RAbsbp0XTksZPCNWDGYIBo2aHDwErhIomYQ0Xluo1WBtH/UmHgirHvclsou1Ks9jyTxiPyUKRfae7GNOFiX99+ZlB27P3t8CjtSO831Ij0IpQrfooZ21YVlUKw0Wy6Ll8EyefyrEYSh8KTm8dQj4O7xxvdg865TLeLpho5PwDRF+/mR3qi8CdGbkEc4pYZQO8UDXUN4S+pe0aTeTqlYw8rRHWF9TnvtpcNzZw== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) MIME-Version: 1.0 X-Stat-Signature: gf7xzeq18qb6nnfhqui1k7kezh4w5okf X-Rspam-User: X-Rspamd-Queue-Id: 993D3100004 X-Rspamd-Server: rspam02 X-HE-Tag: 1724807962-220951 X-HE-Meta: U2FsdGVkX18zM1SGC02CE1u06KcRmQCIMicAtJ0N9CMB9y9NsoynXCrfn1JWgw3nx2x2Ek8kNEqyt1kOHtx3WS9dMXnTPEtutspTQ5KZhERSoWBKWUV2HHQcGu7fjNtK6tdABZFDNOHES2AdE+AfiZAa3BmSkBWIyirIFBXtvhLqKR1w0rX3GJ8bQG8f7SXJW2Qbh5JlZUgKAbeR2NjT+V8+HFGdDj8Z3G9HhlnENjqnisrxj1iVD7mCFAeuymeJa+xuHAma1bB+92RgmkK15lD64BQsWtEOE/S/a3XbZbYNlcBLigjwgWe5nIqGzzhglYHeLxD4ncgjf8VfxmgfTScCA4Yia2bcDiC4MUPhOShJtTyvRVonKR533JE1qLx9truKFnh1V9krn4nOJUqbazuu0WR42Gsr5JISosQZMCfbkVICzOvUtX4LGjsYlr/04ymVyt4X13amasprgJVlRtEqSh1x5EBpN1KoHIlv50U4etEqy0unbcdcu7izh2uajcAlU24M2SlZfNvLYAG+RxCwB9uWZtdMTluyRj0zv1/EZS3MKJ9ynDWd0IxUSzZHuwX6nj+/OvMTh+KxS3hbKRNVwsBDdb01pvwF3q+iyx8wMyJNaY5ehScwcfLDfWAW+uomNTScC1Mg7WkP4B55n21w5qndRsJ2JxLWsBuNNd/90hX4qmo91O8r54x4VIkt0TMrzLAgLP3OI4GIXA4T1ICdZOJYEWkomsy+cMuZEYnunq3A9YaJnVIy+kADYJQ+FtawW9pSbszT3n2yZLeZMFI8APvvCWDgkHPj5efKj0WvbIbCXViOCVhuTDPkF4GB3JXkN0FdME2NqiblCLfhSumUCgWulwZlGIAs/MvjBuIDpyR34t/ASPjlnu7fZw8Z5VEM4v0ipWd2uMWzaqIMUH6n98uh3zHVuWVc2YBqAwCXdOyPvDvZwHq6w9rtj45IPaKqWihQNSDJi9fso97 ZlSAsEPJ 6FQ1liWmimXXqEQmDtyZ2JqiB9QMX3Cy3DiqeUpb1o4Qyu1tO/Obh4AT/H0mclYGjDyMYjYz6nMaNN8O5fFJm4Ca14phgKi9UZlXZrwJTsIbxllXzJsCVPyztlcISzko//pzF1wZVo6/r1eo3nQkTlYxbA6+a/KiHYKuiZyLVDSzib5lb1dyJhMHkjnLQ4uokez/lHa0SvR6NodrBTeZIcqOOKoNbiJwA1083NB5q93hdXZyYiQg0XHQLg8FqORaus6aWAbxmbZ5igegLtJMopGo1+6pF+JpxlNI3 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: On Tue, 2024-08-27 at 13:09 +0200, Johannes Weiner wrote: >=20 > I agree with this. The defer mode is an improvement over the upstream > status quo, no doubt. However, both defer mode and the shrinker solve > the issue of memory waste under pressure, while the shrinker permits > more desirable behavior when memory is abundant. >=20 > So my take is that the shrinker is the way to go, and I don't see a > bonafide usecase for defer mode that the shrinker couldn't cover. >=20 >=20 I would like to take one step back, and think about what some real world workloads might want as a tunable for THP. Workload owners are going to have a real problem trying to figure out what the best value of max_ptes_none should be for their workloads. However, giving workload owners the ability to say "this workload should not waste more than 1GB of memory on zero pages inside THPs", or 500MB, or 4GB or whatever, would then allow the kernel to automatically adjust the max_ptes_none threshold. Once a workload is close to, or exceeding the maximum amount of THP zero page overhead, we could both shrink THPs, and disable direct THP allocation at page fault time for that workload. If we want to give workload owners a predictable, easy to work with tunable, we probably want both the shrinker and the deferred allocation. --=20 All Rights Reversed.