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 8989DC77B75 for ; Sun, 7 May 2023 10:27:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8CAF6B0075; Sun, 7 May 2023 06:27:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D15F56B0078; Sun, 7 May 2023 06:27:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8F296B007B; Sun, 7 May 2023 06:27:22 -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 A6AF06B0075 for ; Sun, 7 May 2023 06:27:22 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 63D24808BE for ; Sun, 7 May 2023 10:27:22 +0000 (UTC) X-FDA: 80763081924.26.17925EB Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf12.hostedemail.com (Postfix) with ESMTP id 60F3240002 for ; Sun, 7 May 2023 10:27:20 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=c+QuWE6E; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683455240; 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=oav2A28KVKDaotNibkAokXcYPyLTU0ijj1klZnIOiRI=; b=gdbABfuAzN1hBkRaLh8A9ZzOb1aabQYZOK6aWYYwHORDPvGpG9IJzHjLz3cLqbRFPoSM5y QdEG+4tKGHMFkrw3XbhqRjeo+RUnVZdQSoWbSw2dUga6qiLwM5ZTj0FdtD/nMEkq8mb0A+ Ncy1+UPuFkRllANNEOqINm8icmNFp3U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683455240; a=rsa-sha256; cv=none; b=ZAhL4fp1NDLhh/6jQgdK57AsfI2RfBSmcGC0AeXrRsWmxvJoAay8MWpWwRixguk4GDtK9o Y9z6E5OdSAZsB/gv2Nyp4q+0aYRr5eKZJBNK1SMUPKkxrDzfIywGWsRonWo+xvj+jj5Xpi w82/BVuGb2qAPVR7O0LNEt+3SYXAfE4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=c+QuWE6E; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0FBA61F459; Sun, 7 May 2023 10:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1683455239; h=from:from:reply-to: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=oav2A28KVKDaotNibkAokXcYPyLTU0ijj1klZnIOiRI=; b=c+QuWE6EU4wWKhietxfwN/3l7yAy0K35os01H7NfRFE82alr8YUVFXQqf5mweH8wlzKf+k lu0AkCEfmwJ2VDmkoLh8SVCJbT4jzXXTf9sUf9reepl+WLoX/HYO+d0q2t7pYqKTvW4ACE 6vuKCAGkjFOK3NT53IiVKVs+9jUJHkc= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E9F17139C3; Sun, 7 May 2023 10:27:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Yy8TOQZ9V2RkOQAAMHmgww (envelope-from ); Sun, 07 May 2023 10:27:18 +0000 Date: Sun, 7 May 2023 12:27:18 +0200 From: Michal Hocko To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, vbabka@suse.cz, 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, ldufour@linux.ibm.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, 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 00/40] Memory allocation profiling Message-ID: References: <20230501165450.15352-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 60F3240002 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: k47gtwdjt4qumbgiytm5yy9n3txsd34f X-HE-Tag: 1683455240-29829 X-HE-Meta: U2FsdGVkX18fBHn7+O8qJikLFx3/FqYyHgobuA2E2xkyzTOke40qulN2HXp8raiTfvxcxq3KuRx3vBD9w5cpefXWkkmHOluQEvI69YFNQkaINhhXWDgMulT5O6F8AOmQwX+wdkOYfjjRp46RqK63Fzi6Kz8W70m+KJUTk7mP+fS6zb/2AIo11XT+kacbz9bszeSKaEJtnEoeAXtvaHn/AyvEu1bP6XQNzjgvz2S3K+NtTJREwpeYwoetPOhw6h988UikgxsDpeIeFOAtEO2dXbZJXa2QLGFDvUTD1l5GTkV1sPDEnQAjFrvrm4Zes7xhGAB/51Tmmjvj6uW8Iha6fuJRf/rVPWXC6kMaEPrBZVvbecBFWc+teOcHXH7fLbDyjWEm/bEuAd6sqYlvozy9F4RR93pkRQcqiJLl92FFuh+LBuNt12VfMMf0/Ihg1KzFVKP9GpwdNzmhJ+x9ilvifISF4oROuIIhSrrI51XWnGYBesP+BXCwpzOzCWaYLJL2zFtAmjODzb7Bft8lQ7hhT82Vj+wc+zikGi8y2BwxZWeqzmRA/zvmA5Lf/D1lOsMOzQGPV3jJo+7SojtmwjX+FjpmajjTmr6QWSOJ/irYI3oRqxkKZY8EjiYRjkg4aGnYDDnFfq/AluifW7uk+DRG+rjOnlyKkOYghqANhxH5bJD2jITGbaZ0757zno/cf6ZfH1K4N0O+63c0GeeL107iFOcnkFAxdhomU1wfZOtOSPx6Ym5KGUyIe/wgxM6/QGaisBA9g30rB0o0mJcLOOWyKisMaNqawb4M/wEHMw99mtzHIE9Xg/Ak8wK84M+7coC6aE+uFrPn0nGp+fp/uZyibBe+ik3EPNY8zvWHmkHJzXIGMN8jOHyOLhUGL5Ck2In3C+xhF2jWyyLiSPRJ5mPa+VPHDY2qYdPla36T+KKZOnxhnkDytLQm7wh1X09X8ygtat1ARtsKXrSeJXkfOQC PEEmla5H T4ovwHNYAaIZ2hRlxx4139DKiCxAgQPTh2F5pxZudHoPTLzedWxhu/958pjWYOjn3igVwcTkyw1Ij9in47iBktpWRO19TDmFEO+HAu8+6ruIYhvmv9ymraWQCbFuLswjiMrBY52tlrhaWL+8UCPROSKyXeg7SPAnPR07WHGIBJG0buqNWsHQWGhWMLhbuU0mUmhc4Ut7cIcagyVX31FjLT2kuXZTz9Mwmpf2Mtde06JbPxLnuws02UFkGPGKruu4LD1iT8qrdB6dB9V4JYqBxXGKjJw== 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: On Thu 04-05-23 08:08:13, Suren Baghdasaryan wrote: > On Thu, May 4, 2023 at 2:07 AM Michal Hocko wrote: [...] > > e.g. is it really interesting to know that there is a likely memory > > leak in seq_file proper doing and allocation? No as it is the specific > > implementation using seq_file that is leaking most likely. There are > > other examples like that See? > > Yes, I see that. One level tracking does not provide all the > information needed to track such issues. Something more informative > would cost more. That's why our proposal is to have a light-weight > mechanism to get a high level picture and then be able to zoom into a > specific area using context capture. If you have ideas to improve > this, I'm open to suggestions. Well, I think that a more scalable approach would be to not track in callers but in the allocator itself. The full stack trace might not be all that important or interesting and maybe even increase the overall overhead but a partial one with a configurable depth would sound more interesting to me. A per cache hastable indexed by stack trace reference and extending slab metadata to store the reference for kfree path won't be free but the overhead might be just acceptable. If the stack unwinding is really too expensive for tracking another option would be to add code tags dynamically to the compiled kernel without any actual code changes. I can imagine the tracing infrastructure could be used for that or maybe even consider compiler plugins to inject code for functions marked as allocators. So the kernel could be instrumented even without eny userspace tooling required by users directly. -- Michal Hocko SUSE Labs