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 67BEBC77B75 for ; Wed, 3 May 2023 19:41:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1515900003; Wed, 3 May 2023 15:41:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC513900002; Wed, 3 May 2023 15:41:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB3F7900003; Wed, 3 May 2023 15:41:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by kanga.kvack.org (Postfix) with ESMTP id 959C2900002 for ; Wed, 3 May 2023 15:41:21 -0400 (EDT) Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-b9e2f227640so4788062276.3 for ; Wed, 03 May 2023 12:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683142881; x=1685734881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7eRiiP2JCtlxvX+BHzTjXxhFfE3xb3L5Tko5xVivHIc=; b=njnY9/ZTWcA0YQLoTf3TUMfGQMs6qBR8x/WiO3YJ4m2rgzn9gPgiVmWeEd3meHgQOd veIE13lp/BEBibiOOZUNO+WD2iQQwInbq0mORyd3+wLWSUTFkhmbMs6fl3Tqmd3D0D5p V+y4b3/jKL+G7UEO8JQopzaWcrHdBR+imlq/VrwTOp1569eYFHFfi9pD7I53OyaoPSYd tj72nQLogAXIm5Pv95noTQ1YRpRrtHa+Dymto/1ndku51s0fuH/R0nkRvqq+7WbyeTBe or08gvlkQ55RtNC4M9pq8YNpCVr1Dsrvti1RMiJ42Ynp3MHUq3DPU/4MOuwmbk5VuygM Oy2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683142881; x=1685734881; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7eRiiP2JCtlxvX+BHzTjXxhFfE3xb3L5Tko5xVivHIc=; b=cRU87RaLfd2ZIe9j+jbH+BmfqVLJq3/LU3Zb7IjcavH4sw7P50CX7+A8Qx/hmYxA4T fpJZ2nh1GmYMIgq6Pyif4zdJ2GuTHPkNlGa0R8ggwBtWVp8Ezdhfxn94T3JVKanIH0DW IXHpDPHroUsMRzTNpdOzakkKpZ89foMeG4efG8u8ABHq6GiTT8o3mFYZVWnsrO8IpAn+ qsejn8ZsC49ty7u5usVckoG0CpLX4Z3u0X54M/eNXixiR8iBaiwRolJ+DoEAq8ozhC5J S2mzAqUbwLEQ80sqPsvzUaKXBHPKlxMHtLJXLueWasf6A+SBe6xAlkviZkMVodTvGRyr Dfmw== X-Gm-Message-State: AC+VfDwUCnE8v2qcjcbE6vtPNo78V2VhaUkozX7nEBya5XMqabmnAbBh ZgDDahGbL4a2ZRCFzYwSrclJ2dck3jILOTbzLmgLHA== X-Google-Smtp-Source: ACHHUZ4RFT+eYjp8zpqFQpuduTlyNDeYqB8fD0xjOEnMllgaLgM5ug7v5zBN549JMpsUAooBfYdYqk6S3BpMrYkFeqQ= X-Received: by 2002:a25:308a:0:b0:b9a:38b2:8069 with SMTP id w132-20020a25308a000000b00b9a38b28069mr18330170ybw.6.1683142880244; Wed, 03 May 2023 12:41:20 -0700 (PDT) MIME-Version: 1.0 References: <20230503180726.GA196054@cmpxchg.org> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 3 May 2023 12:41:08 -0700 Message-ID: Subject: Re: [PATCH 00/40] Memory allocation profiling To: Tejun Heo Cc: Kent Overstreet , Johannes Weiner , Michal Hocko , akpm@linux-foundation.org, vbabka@suse.cz, 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, 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, Alexei Starovoitov , Andrii Nakryiko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, May 3, 2023 at 12:09=E2=80=AFPM Tejun Heo wrote: > > On Wed, May 03, 2023 at 08:58:51AM -1000, Tejun Heo wrote: > > On Wed, May 03, 2023 at 02:56:44PM -0400, Kent Overstreet wrote: > > > On Wed, May 03, 2023 at 08:40:07AM -1000, Tejun Heo wrote: > > > > > Yeah, easy / default visibility argument does make sense to me. > > > > > > > > So, a bit of addition here. If this is the thrust, the debugfs part= seems > > > > rather redundant, right? That's trivially obtainable with tracing /= bpf and > > > > in a more flexible and performant manner. Also, are we happy with r= ecording > > > > just single depth for persistent tracking? IIUC, by single depth you mean no call stack capturing? If so, that's the idea behind the context capture feature so that we can enable it on specific allocations only after we determine there is something interesting there. So, with low-cost persistent tracking we can determine the suspects and then pay some more to investigate those suspects in more detail. > > > > > > Not sure what you're envisioning? > > > > > > I'd consider the debugfs interface pretty integral; it's much more > > > discoverable for users, and it's hardly any code out of the whole > > > patchset. > > > > You can do the same thing with a bpftrace one liner tho. That's rather > > difficult to beat. debugfs seemed like a natural choice for such information. If another interface is more appropriate I'm happy to explore that. > > Ah, shit, I'm an idiot. Sorry. I thought allocations was under /proc and > allocations.ctx under debugfs. I meant allocations.ctx is redundant. Do you mean that we could display allocation context in debugfs/allocations file (for the allocations which we explicitly enabled context capturing)? > > Thanks. > > -- > tejun