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 33E25C77B75 for ; Wed, 3 May 2023 20:15:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D4E9900007; Wed, 3 May 2023 16:15:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9686E900002; Wed, 3 May 2023 16:15:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FEB5900007; Wed, 3 May 2023 16:15:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by kanga.kvack.org (Postfix) with ESMTP id 5943B900002 for ; Wed, 3 May 2023 16:15:20 -0400 (EDT) Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-b9a879cd49cso8100641276.0 for ; Wed, 03 May 2023 13:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683144920; x=1685736920; 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=fJv5xHBTJjNv/pix2rgh9sMW7sCnrk66nOy29HPAlus=; b=UCO8xAxPQELEnJ5Z/+6POOiyN0vC8Y3LS4oWyDMuhEhZvFzcfiun+ebWGPwrO+pD6P oaWSGqmefHbl5lAEiPf5lmUVnYEfPjsrvltc8OpHClJDRLqR0c6JCt2K4/o8XHiKCVdf J53ZnSfM4WQ/BqrKp+eVl6M1p/n6Qe+G3n50PB19Uzdxt6cKRczUS8ApWupvLyGowGSr nGY8DkG6nB+Z74vkrN7ka4kE+r+AVY9ut3CcNzBfOZ5eIHL+qS/vkhlLgZTTLFk7Q8GU 5cYkPlXWlkK/9gZow1krRfzsVVYIijdz+900Nl7CuaPdx5c8WOD0aSivErWELXWkx49V I4sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683144920; x=1685736920; 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=fJv5xHBTJjNv/pix2rgh9sMW7sCnrk66nOy29HPAlus=; b=fOTaXwqqvcLh0HZKYSYWMwvdilfpLS1M3KEkmENhitGYQBHiSv5DA32IeMyX+dcx5N SFKyGzo4pNWmYLT8/cluEYz8Z5oY/oK8yo2unw7O7GPowM8OvcymaRBR1JdI2DuOAE6D V8BuiOrGPxdc3EUNCtX6lMtLw/dN4XE1Alf13uJqETnPo2e2UvEchwDcRdVe6ExyuUU7 ucEGVbuy/iDBcKnHM9rUMiKsi+LU9ES0y76zX8WR3KiLtnLRmOoFTWtzfCf1O2suMF/h mPpckYgeiZFBOtGZDBygyDXCu8R+rAQ70H7/3TtCjliRXQ7Ij7vswjBC+rxjLmhjFdO4 rvnA== X-Gm-Message-State: AC+VfDxuRWxm0af7czhKPyTvkTSnIAIayTI/Vn81lJqj7LRxNRgxAzRa d8wKTohQrhFVaZkKNvUIk8Kayn/+Hte/pUMCC9dIyQ== X-Google-Smtp-Source: ACHHUZ7mImQ/1wXTYz0SIgMaa2LSNhSdXyURzMfJt6GpNMGuq33NeGKiMX4mFybM8LMTHwiJs7q6jFVMM1TC3F7btJ0= X-Received: by 2002:a25:2b45:0:b0:b8e:db20:eccf with SMTP id r66-20020a252b45000000b00b8edb20eccfmr22508398ybr.55.1683144919429; Wed, 03 May 2023 13:15:19 -0700 (PDT) MIME-Version: 1.0 References: <20230503180726.GA196054@cmpxchg.org> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 3 May 2023 13:14:57 -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 1:00=E2=80=AFPM Tejun Heo wrote: > > Hello, > > On Wed, May 03, 2023 at 09:48:55AM -1000, Tejun Heo wrote: > > > 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 i= s > > > something interesting there. So, with low-cost persistent tracking we > > > can determine the suspects and then pay some more to investigate thos= e > > > suspects in more detail. > > > > Yeah, I was wondering whether it'd be useful to have that configurable = so > > that it'd be possible for a user to say "I'm okay with the cost, please > > track more context per allocation". Given that tracking the immediate c= aller > > is already a huge improvement and narrowing it down from there using > > existing tools shouldn't be that difficult, I don't think this is a blo= cker > > in any way. It just bothers me a bit that the code is structured so tha= t > > source line is the main abstraction. > > Another related question. So, the reason for macro'ing stuff is needed is > because you want to print the line directly from kernel, right? The main reason is because we want to inject a code tag at the location of the call. If we have a code tag injected at every allocation call, then finding the allocation counter (code tag) to operate takes no time. > Is that > really necessary? Values from __builtin_return_address() can easily be > printed out as function+offset from kernel which already gives most of th= e > necessary information for triaging and mapping that back to source line f= rom > userspace isn't difficult. Wouldn't using __builtin_return_address() make > the whole thing a lot simpler? If we do that we have to associate that address with the allocation counter at runtime on the first allocation and look it up on all following allocations. That introduces the overhead which we are trying to avoid by using macros. > > Thanks. > > -- > tejun