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 00DE9C77B7F for ; Wed, 3 May 2023 18:07:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8074A6B0083; Wed, 3 May 2023 14:07:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B8336B0085; Wed, 3 May 2023 14:07:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6CE216B0087; Wed, 3 May 2023 14:07:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by kanga.kvack.org (Postfix) with ESMTP id 490C96B0083 for ; Wed, 3 May 2023 14:07:55 -0400 (EDT) Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-b9a6d9dcbebso4602866276.2 for ; Wed, 03 May 2023 11:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683137275; x=1685729275; 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=lYpn5fAZ9k+tc7itapEv1evmei0G939nEHfVs4IvTnU=; b=CiPRLrpSjqW+fOh4MZzhage7DRZ0A4p0DiZA5jkP6SoRdijKTb12IH8HPYoav3LVEG UxuWUsJ8XzpNsPDm/IXDURhwANLIszVcD7BHVZWpxKR8Cw0scnMG0+3659JdLK1Cnzbt gTx327NEx/KsnLGXWD2bm6c3nHMqUhK1ehp/AZAyLh+gV85XesNeu4FfbGmllcRcS3lj 8b1rxia0KH86OKF4Rdr+PF90kA/tWE7FmwRSBvJAJbjNt9nt9Qc9maZ0a63/0iDWxZfb BP/YCRNb1VC6qYWZToRLJOzAfLm4sCL3eqAVGEOxe8HA1U7xEqqPmLc8gyCiBCpRmk5A q7WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683137275; x=1685729275; 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=lYpn5fAZ9k+tc7itapEv1evmei0G939nEHfVs4IvTnU=; b=Yzfyug/2QtyvNI/EuNEmnebIfAtugx5O4vHqUntREqAwQ6sGSdujHHGWu7i26pGAit E+2uRgffS+nmpSpY1mZo+o2wbwbk/jYRB0/L4VZaCzbyGrHZvopjB53f/usiJP3x+dfN jrH84i4V8qCUQlzg0cWyB+ztE81KrIDhg4/QYtWjPd5HyvOGjRAX0/l4aquB3lwG0op1 BRwwZdApuKBi0A8OeXJK9oLfMQI0XEfdGS8eQBtEkxqR7fbLGS41apwOZhNjNb+4Snx0 EZ1dFGa+2KFoTaqR03DaMq6nh2nSlfFvw00M/DHKsvDhMJhdCpnYpbjTX6GV9uZwLiVK yRog== X-Gm-Message-State: AC+VfDz3AeaX15652GI8f5tsvCBAlLeXvanJ/MOqwlujwFYB575NxYdW G/TPrnnQm7Ogm3icbTaVCFbHRwIZBeEuLshk7g2PCw== X-Google-Smtp-Source: ACHHUZ6ziLHqDMkaJeUajgwvpj2QvaNH2BhqMrvwwDmHlXu07PkkROglIzhY18q19oBr8s5xwayGmOGDhyIKmdbKiGw= X-Received: by 2002:a25:160a:0:b0:b9e:2697:9d96 with SMTP id 10-20020a25160a000000b00b9e26979d96mr9339675ybw.3.1683137274526; Wed, 03 May 2023 11:07:54 -0700 (PDT) MIME-Version: 1.0 References: <20230501165450.15352-1-surenb@google.com> <20230503122839.0d9934c5@gandalf.local.home> <20230503140337.0f7127b2@gandalf.local.home> In-Reply-To: <20230503140337.0f7127b2@gandalf.local.home> From: Suren Baghdasaryan Date: Wed, 3 May 2023 11:07:43 -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 11:03=E2=80=AFAM Steven Rostedt wrote: > > On Wed, 3 May 2023 10:40:42 -0700 > Suren Baghdasaryan wrote: > > > > This approach is actually quite common, especially since tagging ever= y > > > instance is usually overkill, as if you trace function calls in a run= ning > > > 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 tha= t will > > > never be used. If run time allocation is possible, that is usually th= e > > > 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, tha= t > would be more rationale to do so. As I noted, this issue is minor since we can be smart about how we allocate these entries. The main issue is the performance overhead. The kmalloc path is extremely fast and very hot. Even adding a per-cpu increment in our patchset has a 35% overhead. Adding an additional lookup here would prevent us from having it enabled all the time in production. > > -- Steve