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 D9835C7EE21 for ; Wed, 3 May 2023 18:03:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76D4C6B007B; Wed, 3 May 2023 14:03:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CFA16B007D; Wed, 3 May 2023 14:03:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 597A16B007E; Wed, 3 May 2023 14:03:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by kanga.kvack.org (Postfix) with ESMTP id 42B076B007B for ; Wed, 3 May 2023 14:03:47 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8182262F2B; Wed, 3 May 2023 18:03:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04F9CC433EF; Wed, 3 May 2023 18:03:38 +0000 (UTC) Date: Wed, 3 May 2023 14:03:37 -0400 From: Steven Rostedt To: Suren Baghdasaryan 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 Subject: Re: [PATCH 00/40] Memory allocation profiling Message-ID: <20230503140337.0f7127b2@gandalf.local.home> In-Reply-To: References: <20230501165450.15352-1-surenb@google.com> <20230503122839.0d9934c5@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 3 May 2023 10:40:42 -0700 Suren Baghdasaryan wrote: > > 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 will > > 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. If it's not that big, then allocating at runtime should not be an issue either. If runtime allocation can make it less intrusive to the code, that would be more rationale to do so. -- Steve