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 CCBE6C4829E for ; Thu, 15 Feb 2024 22:54:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CBF16B006E; Thu, 15 Feb 2024 17:54:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 27BE48D0001; Thu, 15 Feb 2024 17:54:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 143FA6B0088; Thu, 15 Feb 2024 17:54:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 023C36B006E for ; Thu, 15 Feb 2024 17:54:41 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C7993140467 for ; Thu, 15 Feb 2024 22:54:41 +0000 (UTC) X-FDA: 81795544362.23.F670FE8 Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) by imf26.hostedemail.com (Postfix) with ESMTP id EFF3C140003 for ; Thu, 15 Feb 2024 22:54:38 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=s7GjinpF; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708037679; 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=ZDSi9l3t5jb4xqm42oA6b90TgSdD5o5/qEQqj726Xko=; b=hg6gCAm2lQvNNLYJKM23R+Ep2pEM51QOVqgq6fnVpNKeTFAhCTEbg4gsQ+VpUAvx9b54zM 44B9G16z9uDDkVuI1zM+V/SvzLecipPebuVIByYbczW8CrGrtmGxs+UqDbNbteamF3cfSO PcIrWOlIPLT+Ury39cGuSnvjiBJUZMY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=s7GjinpF; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708037679; a=rsa-sha256; cv=none; b=xpy7zo9o84IcsUnPOPKrP+LZWyaslvinKuWHJaIOyM0oH0GjHIp1/d5BUZtrY59WUc0AMn i70cQEv0jJtK1KALQAewY5LwYC3HZbejQo+jlQnS6VHaMKCHuQpInjAnWkO9TZfyA3adnF IS6NkJ+dVrYTEaJ7tdMyrF6uszckrTU= Date: Thu, 15 Feb 2024 17:54:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1708037676; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZDSi9l3t5jb4xqm42oA6b90TgSdD5o5/qEQqj726Xko=; b=s7GjinpFAKYCSUH++IShUfbdX2oRHH7jMoJOiFXnURQJriQJpk2c1g6IKodkBsWFrf3tMo lRA7KcUWR9thLhS4EQcOGTvPoXKrv2i+J/AXkZWZfF3jhzdVpibqSVtKnHN1t1gucGHdc8 uhGVZUZbURioLMmI/fU2b1rDFnFpKMs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Vlastimil Babka , Suren Baghdasaryan , akpm@linux-foundation.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Subject: Re: [PATCH v3 31/35] lib: add memory allocations report in show_mem() Message-ID: References: <20240212213922.783301-1-surenb@google.com> <20240212213922.783301-32-surenb@google.com> <320cd134-b767-4f29-869b-d219793ba8a1@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: EFF3C140003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 8mbmiw3t9eutmp9ct6u9584amdt6pkye X-HE-Tag: 1708037678-715266 X-HE-Meta: U2FsdGVkX1827cDrIsKVm6QUgEj7Oid8ZzDB8aGKE37aEc9q1nBTuqZGxPT1R2zq2RjT1pSX9mubRGkEMfLWDuEos0qoK8H7Kykm6q9ID1goP77bMfmlQRubZimTrx9NueJC3X3O4UaukONZFAY3pYR62JAgbJDKF9218enQwE/xCLVT+y7ogiNglmHvyY6MJj9uK6YUISCAmEDvfHXHCf+93g8kEAfPn/ut//kinyPFRguG5SXG0GQFKRuthOxcNWJlXmK6ikMfjrJQze1+YX3gU7RKLVymQJOWpW/WBO/z3NUCgjsbLOoiRu+S9tYbbkoxDwDNX976b+kd34TQOwo7TeJC9+D8d0YdWynCsd4dO0SvkjeFuzlOTRYK8WV8v6wSAOR3QdAEZMinh28+Gb1wQjZem/OA8q8BSaH9oR+s5FgIq0N3lIVZDRFLjRJZC7R1aKCzYUpFMLjeQCsq0RZS6w5ocgNCQxAYqqlACCQ3varwzCY/PHzOCdr1tyXmZbFjw6KFfqYjwr7+IyN5GCeB8NAG/W/79d1lGi9DDOQbGchCnNFhYtw4E/GhnabOlcffbm1fb4mwRIvZHl/8KkW7jz6+lETrpEN7WBkdEiuGa58IcRzV3DxecUuhlVnYOVqHVnIoXpiczOaVYG7iKWPTdEeiRk8biB8Uul2cy/FeouMx5vCrIdGZ7f2wnhDe26/JUlTWTvRtUlQgE42g2a/a8gQ3FRWHs4mDiTafDjISwgBuXysHKDFUApoqAsLf1G1cevS6J7Ca/Q0yWv8Q9D3LpS6lrYzJqAvQs1pjpfS12yoqtEoPiAVU9w93FzgJpZPgekRGH8aoQZpxQXlM3+2pJ4ALKd4GzymcvbWvxB783UrW8c6qoq9m1f+1R8kLQ+NXm+JycYOih7jXMH00UXQpzDumdNCxOMJ3uJDG1wnVq7kACvOElMgepfYgY2C6qnlGSZ7EWTOnMEY0OSt eA8v6vmC rEVHvA1CcNgmlmd+12troV8KJ/S1UEs9n+KJsWhTJ2dLs2qr4t9PXP7FkVo5jNGKW8sJIYjQF8+tNPsxvv/ZSp/NwsJ4ZLTkmfTHT3X8m1EXmXRHr/GUurTm2+kffdd5s6MWITkn2LijOriQFmg5bESCbRtX3j10pyslkaaP12u7C9E5aPu5gVBUbbaBPjK540kn5 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 Thu, Feb 15, 2024 at 10:54:53PM +0100, Michal Hocko wrote: > On Thu 15-02-24 15:33:30, Kent Overstreet wrote: > > If we want this report to be 100% reliable, then yes the preallocated > > buffer makes sense - but I don't think 100% makes sense here; I think we > > can accept ~99% and give back that 4k. > > Think about that from the memory reserves consumers. The atomic reserve > is a scarse resource and now you want to use it for debugging purposes > for which you could have preallocated. _Memory_ is a finite resource that we shouldn't be using unnecessarily. We don't need this for the entire time we're under memory pressure; just the short duration it takes to generate the report, then it's back available for other users. You would have us dedicate 4k, from system bootup, that can never be used by other users. Again: this makes no sense. The whole point of having watermarks and shared reserves is so that every codepath doesn't have to have its own dedicated, private reserve, so that we can make better use of a shared finite resource.