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 5C973C77B75 for ; Wed, 3 May 2023 18:08:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbjECSIP (ORCPT ); Wed, 3 May 2023 14:08:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229711AbjECSIO (ORCPT ); Wed, 3 May 2023 14:08:14 -0400 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D34991FDB for ; Wed, 3 May 2023 11:07:55 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-b9e27684b53so3221624276.0 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=I0pKS89/CBKLwG7wZ0BOR5dbA4qhSiyaYNfYJeei0QDoAfGXW9baQ3wJhsxGXSa2WR i+qoIJA4wTCvzA8SP6Zhm+w07udePkIVkmiCn5+RCfp5zDNT55JYxE3iga4XndR533Df jMc5O/4Z3ZrQZTWahfwr5A0SAdZ2Ngwu98GGcTi0LibXdrn/dFQ0QUrFDCmRD9twGqVq yXl36M6zsMGtE4/Fh6O5QWoWwf+pdbTFmgnfaK1KCVyRsseLxr7Wetsx8GGWogOBF0on sPCQoMEf1xI2jI93cXsEA+ZaTwC1SyMdMFi7aEwtTnyi3USyGZaroIiLGmzAmvFixPYs GI4Q== X-Gm-Message-State: AC+VfDwCv4UddSW/jzvz8WB3O0VADBUx4vGYER2MdtJ6e3r9TYvXcEOr A7Fx1E91rImHTjSUrWB2ajDeEwQGOAwAkpf/iAQbNA== 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 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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