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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 073F0C77B7F for ; Wed, 3 May 2023 19:41:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229938AbjECTlY (ORCPT ); Wed, 3 May 2023 15:41:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbjECTlX (ORCPT ); Wed, 3 May 2023 15:41:23 -0400 Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D65CF76A0 for ; Wed, 3 May 2023 12:41:21 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-b9ef06cb784so2160066276.0 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=LM+Xv756xiIll6lkHbCUFUpYX8OXE+eIffjeqG2Ue17UJuvBlampovo9IQqFY46uqx zO8HKOfn2QSQD/BXk/7cGrCoeNC1UD5YTt38NpSj37Ft2ucoxmpvkEJc+h5Rpa6ffb7z sQGYrX4bnkVGOzwl5bi0xBq3m6fqCn/Rycrk75Isv/z5yESHGU+tUeFpHSAG8HiaQZgg PCTSgKP1E8Ede3aOyKHsa3ijonza8FimXjlO3xIpdDAKdVVltZxHjT1r6ejBfeuVaH+G 8TicSgjdWiUfhQLdVUhd4ylq4KU1Z2gMRkAnie6CMAiut0HaaDdbjO8bzuGYNFj8T+dr GEjA== X-Gm-Message-State: AC+VfDyawNp01TdCt3ZLJJsvaoS3dHF7dY0dBUOBSlcpjaxoluZii4mm njggoZc5ImVC5XsS0qq4wHF/rsCm2BMsAaDijpAvpg== 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 Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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