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 D2928C54E58 for ; Thu, 21 Mar 2024 20:42:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47A996B0089; Thu, 21 Mar 2024 16:42:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42AFA6B008C; Thu, 21 Mar 2024 16:42:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CAFF6B0092; Thu, 21 Mar 2024 16:42:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1CCBE6B0089 for ; Thu, 21 Mar 2024 16:42:04 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AFCE2C02D7 for ; Thu, 21 Mar 2024 20:42:03 +0000 (UTC) X-FDA: 81922218126.17.0BB3C4F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id ED71E180012 for ; Thu, 21 Mar 2024 20:42:01 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sk1DY3Jk; dmarc=none; spf=pass (imf16.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711053722; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QP+JQo1CgM5u8YYrCl4YjBve+Yz5RLgzVzonW1Zokc4=; b=I7QujgianC9hheiThZlSgdcw6PZRHA3s5PRSsHTdTzLCBG/nkNN4j7IUf20BCo0u53PLnS fGl6jdSXvOb39SWoG9MY6lWuR+X7Ltn7NxxPG+is9rI5US3mKQuT8BocEC7+/PfJKVo+tb nvmPrmmFxehRHVfC9sMWzUVRfW9N3Bo= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sk1DY3Jk; dmarc=none; spf=pass (imf16.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711053722; a=rsa-sha256; cv=none; b=4ddetMmqvAHX14GPGGyX622OGhAQBXhZuTTUyuWHoQqkUrFmhBAAhUi3pFd4DIEl9iUczA JkXyHszdZh9popNFOxwYE6ofYnj+z2+iGX8MwNYitOis3MKXArP7SYW5G2T692ANQZYyhf EuT56S/fNcBt18NiS2gAfDaaKPJW4So= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CBFDF6125A; Thu, 21 Mar 2024 20:42:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D384C433C7; Thu, 21 Mar 2024 20:41:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1711053720; bh=bsLnMq6f9MuSXEybZlFqoUeze7bLA8PKxbpvqrgPFq0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sk1DY3JksFP68PjXEwOnUAq1Vd5lNUolSDYThGrqzyyqLQr4fombyuh40LdrgfYbW Ac/65wSglYIyyBBtUS08I78shDAf7A7GSt+MOEK7LRTFv12fDEKGSsGGb3if8rK0ti YWcirP5763C8DrAMcFLznADKk78RtFDyLeMAKgoA= Date: Thu, 21 Mar 2024 13:41:57 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: kent.overstreet@linux.dev, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, penguin-kernel@i-love.sakura.ne.jp, 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, jhubbard@nvidia.com, 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, songmuchun@bytedance.com, jbaron@akamai.com, aliceryhl@google.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 v6 00/37] Memory allocation profiling Message-Id: <20240321134157.212f0fbe1c03479c01e8a69e@linux-foundation.org> In-Reply-To: <20240321163705.3067592-1-surenb@google.com> References: <20240321163705.3067592-1-surenb@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: ED71E180012 X-Stat-Signature: 9uyy1yoid8g68eip476c9g7bnokmrsoa X-Rspam-User: X-HE-Tag: 1711053721-96318 X-HE-Meta: U2FsdGVkX1/E5+F8d8MAQPBF7Wu2uH9DJn2OBHLOLqLBoN1r/0mPK2+/nU67SF42pjWTE/x43VUI8RPGYJBIYdkAL/iY0IPeo9NPRcl/9Y9TeXxjtvKDqZA+AR1oZyLt+45NaCTzFVnXqLIpkDx2h/YLrpv/GbcCnwPtk6ldn1rgdgqdahvfc1y4L/hzUQypffIe+o05ZS9D2CDd1TrJ41pG6mEkKgZLFU63tzZ4X9ShgRrgBbZy66Zjc9fyV+7pwv/yfYpuM1Ta71Y8b/+3RQzPZJL7aSzrpG2puDHRDqCgSOMUrar2Mm6oTmpmDqiTzXVuE64QVR7lMzAwMpik9U/cQygghIuQK8D9v3c9c1W+ivnL57kFgKBipJbRnyBwx8waMBuvq4kcEf308uOPDaq9811N+RNmcywPlIbG1bHG1to6CIW4XiRbTdfRPTLrr7bGJqQKRpV8iD6ELShmOq7hN/DULMkzHlxQagoTmR2ePUOS1VAn5NzqKeKQ+pr0TT6FNWP5diM35KZgex7m8pKqaCpfKM3ckqqp2TzZ6LFFbE6R3E1tWsY93rYzSXJb6EBKISxWKk5/HN/cQJtol6ZVon/58iDrDbEbhz21ntbl2Ot6WzldbSQxngGBiNwLi3KS8DrMUS51bdOUitEoKfCbat71DiSvsDZyZ/qajU6699zvLE9YhKesdSkmMY7xEgfeTkh5J5bRDKpylcyOL6mGy82C2zg61CXGNU20VECfTcWC+qBY45dcp5dn7F9teLEFft5DT6f8nkh96x3oE5/m1z9IsAjDbJF7RThppUw8PzyVqYE7LeozlAmiYsdZBwafl019vOcQSUav2H/fKWDaPDw+zZFHtCyhUmdlfket022Mso/1pvVWG+HUkuLs+LpqTKn4mH8uC+AOUlP3SWgZQ2/MVRXWoLCvzFocaUZ5IMK1atmGkdwsPL+8xoxRStgvlqAMx8SOAMf3Y7q CFrN5d+s T0yGe3YeijqAV8r9vIgHfI4+Fio1Q5TCVawyrqydqK00Ya4KDRG5B5d9ICZp94kvJcZnlnNVDt8vpfH3MQbcLtYgveZcPYI5lz46kHdGWa/OGK/2MTotRES3u152NAmwLF6lQ89LsMtAVznM2P3CK78u7Xo6xt21EERT2ybYici62t1sRiGHpW5/vH/W7WojLEKMM+akAZbltQyyWu2E6q3YnaggGYJTByKtfDXMpv2qxSiVKmc78Q3OLEHApgCFTzI8bXnJ6E7pTL+Y2xaka8KIFbNQrbyzD8iB2U3ia6hmJflGTjklpwbiZMAdxRYyXA4P7 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, 21 Mar 2024 09:36:22 -0700 Suren Baghdasaryan wrote: > Low overhead [1] per-callsite memory allocation profiling. Not just for > debug kernels, overhead low enough to be deployed in production. > > Example output: > root@moria-kvm:~# sort -rn /proc/allocinfo > 127664128 31168 mm/page_ext.c:270 func:alloc_page_ext > 56373248 4737 mm/slub.c:2259 func:alloc_slab_page > 14880768 3633 mm/readahead.c:247 func:page_cache_ra_unbounded > 14417920 3520 mm/mm_init.c:2530 func:alloc_large_system_hash > 13377536 234 block/blk-mq.c:3421 func:blk_mq_alloc_rqs > 11718656 2861 mm/filemap.c:1919 func:__filemap_get_folio > 9192960 2800 kernel/fork.c:307 func:alloc_thread_stack_node > 4206592 4 net/netfilter/nf_conntrack_core.c:2567 func:nf_ct_alloc_hashtable > 4136960 1010 drivers/staging/ctagmod/ctagmod.c:20 [ctagmod] func:ctagmod_start > 3940352 962 mm/memory.c:4214 func:alloc_anon_folio > 2894464 22613 fs/kernfs/dir.c:615 func:__kernfs_new_node Did you consider adding a knob to permit all the data to be wiped out? So people can zap everything, run the chosen workload then go see what happened? Of course, this can be done in userspace by taking a snapshot before and after, then crunching on the two....