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 DDFA4C77B7F for ; Wed, 3 May 2023 17:40:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26CEB6B0072; Wed, 3 May 2023 13:40:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21CB76B0075; Wed, 3 May 2023 13:40:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10B8E6B007D; Wed, 3 May 2023 13:40:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by kanga.kvack.org (Postfix) with ESMTP id EA5566B0072 for ; Wed, 3 May 2023 13:40:54 -0400 (EDT) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-55a1462f9f6so42183907b3.3 for ; Wed, 03 May 2023 10:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683135654; x=1685727654; 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=VnWJwoqbKS+XkHViPIVupavn1s9FL+9QLrnitzrqP5g=; b=eK3o90MKtG0sAxJkQzBjjPPdgC8Naf0DW8LSnzzFyGy7r2iplN6tx8LRS+K1pesqQ/ +dlPpm9XhI5MpmbmybPkhrAEcSQe8jXQWxke9zLF0oWZbujbmGNiLr16iUXkN33UUHSx XBXGIEWcktzdHazuLFLqwBuOkd1R9zqRh1rR05EQP6mEIW+Y870cMvkQ+YZdkTbO3EXe JnQPUyB6BIyM6BqPoFJBWX+ubIIjmGY6Y6TRZTV6HlKG9bq6FA2QoEZiVTg495moZLJm 8j7J7Vy9fMLWKuo3JHmpkQUMBoO2kqt3hu+UuR0WJjg5iixGZu5y4Lvke1eQTwl5WZQa NpXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683135654; x=1685727654; 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=VnWJwoqbKS+XkHViPIVupavn1s9FL+9QLrnitzrqP5g=; b=F4arkU2C3YqWRJjB6GpsxZ4Kjh73B2yIsl0z6suydGhgTv7P9RxVi92fmZ19Xa/tIN gno0XCfFSrhp8DXH5P7AaiRp5Qf31XvTFV+xV+xE4wMp74AHWOyrXYxV9aaGNUCEj8Nu kCDr7GcyX2i5nnLx1z46oQxfQeHZTJS1A6fbCtJXgfDvyWpfjFFiEu6lJXJ/ea8C8fcw TG6ZYNS5Z0DpWBbH1y5MsRKqwU9T/UxDlfmbuLeJe93EcnTCrR4aUSW1Eb2L9CSbE9xb RqshV3kIz1vZZmYCcMO1tndyXcNvhdYC2sOzT7Y+w7LFdDn06DCLWGCIAazUFZonZrmk T5EQ== X-Gm-Message-State: AC+VfDyNUTYVgNDm7Q8FK4tWDECqYiCRnql86BpkWw555oxudQCq3e7J cLMau30It/ntepL+vVJuyxaCdPj4BUZkueWImr1f2w== X-Google-Smtp-Source: ACHHUZ5+xgmBEFDJhkEbV6hOZk2BeNhUs5riMMl8CEWVIZEPl5lRwY7k05WxOPH80Nz6y5uKgnKRw8/1iWaKnQTfG2Y= X-Received: by 2002:a25:1885:0:b0:b92:3f59:26e with SMTP id 127-20020a251885000000b00b923f59026emr18942712yby.41.1683135654167; Wed, 03 May 2023 10:40:54 -0700 (PDT) MIME-Version: 1.0 References: <20230501165450.15352-1-surenb@google.com> <20230503122839.0d9934c5@gandalf.local.home> In-Reply-To: <20230503122839.0d9934c5@gandalf.local.home> From: Suren Baghdasaryan Date: Wed, 3 May 2023 10:40:42 -0700 Message-ID: Subject: Re: [PATCH 00/40] Memory allocation profiling To: Steven Rostedt Cc: Michal Hocko , 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, 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 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 9:28=E2=80=AFAM Steven Rostedt = wrote: > > On Wed, 3 May 2023 08:09:28 -0700 > Suren Baghdasaryan wrote: > > > There is another issue, which I think can be solved in a smart way but > > will either affect performance or would require more memory. With the > > tracing approach we don't know beforehand how many individual > > allocation sites exist, so we have to allocate code tags (or similar > > structures for counting) at runtime vs compile time. We can be smart > > about it and allocate in batches or even preallocate more than we need > > beforehand but, as I said, it will require some kind of compromise. > > This approach is actually quite common, especially since tagging every > instance is usually overkill, as if you trace function calls in a running > kernel, you will find that only a small percentage of the kernel ever > executes. It's possible that you will be allocating a lot of tags that wi= ll > never be used. If run time allocation is possible, that is usually the > better approach. True but the memory overhead should not be prohibitive here. As a ballpark number, on my machine I see there are 4838 individual allocation locations and each codetag structure is 32 bytes, so that's 152KB. > > -- Steve