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 C1026C77B7D for ; Sun, 7 May 2023 17:02:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2C906B007B; Sun, 7 May 2023 13:02:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDC3A6B007D; Sun, 7 May 2023 13:02:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA4CB6B007E; Sun, 7 May 2023 13:02:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B901A6B007B for ; Sun, 7 May 2023 13:02:15 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7CBD3140E5F for ; Sun, 7 May 2023 17:02:15 +0000 (UTC) X-FDA: 80764077030.07.3E86847 Received: from out-21.mta1.migadu.com (out-21.mta1.migadu.com [95.215.58.21]) by imf28.hostedemail.com (Postfix) with ESMTP id 4E45FC0008 for ; Sun, 7 May 2023 17:02:12 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=RBllo5SE; spf=pass (imf28.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.21 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683478933; 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=K2IKs9gP6n8AwGF/yIy3vUTevnAld9lGncsxDoAPz7I=; b=Wg/zGGk8YKg1tJvyFtvhSM3RYx4PQoWrfH6naGFID1nBtxtLWAbOMCW4ngcxz5H2X7XCwa 57SjdjCaIM5EzzFjRVoWYM3j06FpWyq1MiirDGHSdpTM22277UBIcCj+uiAGRU0yTPBMfG s4XMd7XnhXGeX6kD4+c1bRNWZj37fms= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=RBllo5SE; spf=pass (imf28.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.21 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683478933; a=rsa-sha256; cv=none; b=7V5nxmZXU4ouLojQ49aF3UZMJ1DqogAFFvWnGdryHUFCpDMhCfNcmFughCLdRTg+87khqu x3FQlw9osmcALBGnmoJ6eg8qHyNdeW7tH4boKmPI2MUMgEDMCNgAd7xGNthbDva8PE6pG1 gV6BCsKUXdYqAi2fQoFvRsvOKFtAS94= Date: Sun, 7 May 2023 13:01:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683478930; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K2IKs9gP6n8AwGF/yIy3vUTevnAld9lGncsxDoAPz7I=; b=RBllo5SEteiXdDXnxk7cvHhWc/ZZh0WQhZDZBnP+ByAnv8lRSeIbU166BGu3cTiWFAlwdB nBFEChtqdNB9Z3bo6qijnMaFFiQ4D4cogj6akL7Hso38B4dGgPNp5YpE0GoUhkJAbR1zsk SwoHfdcoAv3j3qWwaVk8QGGqXSvbXYE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Suren Baghdasaryan , akpm@linux-foundation.org, 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-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4E45FC0008 X-Stat-Signature: emqfacx6ragqht8yhjxd5sjx98pgsgnj X-HE-Tag: 1683478932-927787 X-HE-Meta: U2FsdGVkX1++7YVJkiiykFAkb7QTuEmUWZ78jNxlrDafFPhmHRppIeUDf2p4T3eV7FvSqe5tUkQlVNw1egtBE1IbWQj7xrQZxIodtFUyFptntwT9jj9p+jXf8RkWjFwl/rJrK7TTiZmQYJkwSrlVRfZ56+kaPJwKqDycPGL8wfO5ge5k8DBm8bsGRJ8/4B17ImyjkxuN00Lnus7UZIsKmyELLJV1CiXStgSLFUNlQ8NIL3Kx/FIlasa5D6wgi8XxRfzzD1RD1rYl0T8Ed491s1yMyN48MtVh71d56kb4b2Lr3x3tCo04axk5Qw6c2ES6EXOxUbr6ETChtTlT/K+Y/LUqiCJmZcQaWj5BCdU4dv9LZ2JIIun4sZiP5Vswi9je7J4InK1KHLa95/+uUmqePg2yiSG4tGXsvqbYwUx8HbI+5KUQrIPmnQxuHJ2ADgvZZbFgWNQMTRBzja1CeGNc5hmusr7dFudXDcWFG8aqqCjQF/wUZK2hYs3pqR08f6nIx+lsgVseEYz9YCnNAFnxhYO5FQjYCqUTE73pcg5tl2PIH3gJricn1xc8SlPzgDlzqNtJ78gEX3vv4SfAqCcNwLtuW6fK0bZqbi8j5TvRXtbbZMqvw4gtoziWRlGyXHPkqDx6VE2/iDLgekto4XD5LGM72U3YhpvbZ5Qz6b2TqmeSUx9LMnXIr/Z2aJJ/TYSJhAJsopGUkeyvknRGmH6fotStiPeOWU2mXQ8cmvQPkuQnoZrYN6vFMAxlKAXLh82kMR8MVQm5LsBIiEFPRvsjNDiWKjCxc/rWq1O5Zxrw5V7li8TMRLMI4CYpr+swhtx94u6dH5km0sSg3L5d2qZV5vWOM+jbBQ/mKeO1oW8PZMx13NH4uLPdazcv6b0CxP1KTaNyvJbdQq22y7dMpfNJl1XACGU75KbfQqAJpyXJ0Abuqvr5+2SDcOKI2KWTi5ZqQB2hPSQl+ujnMgOBRJZ 65xR7Cip EtbA+EG41JxZCiGFZXJAASWW3a64y86/4tbl5mj30l2y7kpF5xpCtsZmbCzqtNfEGU3MlnB7VVHWl0BfPQHqbNrh133zW0i9kyn1FtQR+PDJsrxPQbReV9RPQqB8xglxI66JhqeRiCsWqQpNooCUr9eXMJ006qxB9gbhbHmSdqbVh5q8g9+s/8n37/g== 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 Sun, May 07, 2023 at 12:27:18PM +0200, Michal Hocko wrote: > 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. How would you propose to annotate what call chains need what depth of stack trace recorded? How would you propose to make this performant?