Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp22656pxb; Thu, 14 Apr 2022 15:05:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+cnhDtRNItqd7BuaA83Gg5Z1lvKSvx4GYs6E8E4vpRee6Jf0kPiLNBWZS8D5+ekQXGoR+ X-Received: by 2002:a05:6402:3712:b0:416:13bf:4fc5 with SMTP id ek18-20020a056402371200b0041613bf4fc5mr5244963edb.115.1649973952259; Thu, 14 Apr 2022 15:05:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649973952; cv=none; d=google.com; s=arc-20160816; b=vx16a0cpqYitKitFwtPCnEfhurrqojsDl6LR1qOvfoFZcbmz3G3yX27TGOAGhpCYH8 CXJhtznAN1ynyvihXDTPR/4b1NbPAnhzc5Ny7ZqynE7W9v1ciaIUX7mhojnSvFTcieJi pHX40Zotk7OHQGFe6z4ko7MJaQ0kWDyzKbMiTzPz1CHBFQmDNkRy79Lw0fsn5/EQWoz9 pN0JA8KTzs/WShhD0qQOoL9gyew2HMl8qD6bLY4pv3oLqFx2Zz4bkBPg7kWpv7eQ4XMj /GGSlj2Fv9gANeYwfjC5MxKAe21xIOda+i69GJjs1q6hY5xyGkEOhUOupiffI+pQJZ7f yYuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=CujCbp/sw+khaMiFxer85R28JC7xz+rn3pwqBuSA5a8=; b=QlqemT+2EUcp2WZTdUOXNDC4AXYeeYe/15NTwnK6q1x4QiVn/PvXssTxFowufbCp/o vFd4ysD/+lbC8PH65Myjfn2TsmWCYvY4lmuYLMpayZQVnrA4G+RqJbLI5PJELwDt4uqM JnCSLAm5xinpG3F5ZfQwBqHzDkK6tjkMSU1DQjwxR5i9QmGbyGqn65N2T5Yki5UoYKSr pEkFLe06/7WVzuHIAhepsJonyWcaURdkDmIuyVDWmzm/l1lycvVO57tEgB9QuxTI//Pb Pxsvfjbqe82rMdOCEc0Lf4ROClYJy6z95jzaRlQCHZq/aWPvwK3Q2/CqVVhBnjPrIB5Y uuEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gw11-20020a170906f14b00b006e82ffe65b6si2837028ejb.935.2022.04.14.15.05.23; Thu, 14 Apr 2022 15:05:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238297AbiDMUbA (ORCPT + 99 others); Wed, 13 Apr 2022 16:31:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237426AbiDMUa5 (ORCPT ); Wed, 13 Apr 2022 16:30:57 -0400 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1095C83B0B; Wed, 13 Apr 2022 13:28:34 -0700 (PDT) Received: by mail-lf1-f50.google.com with SMTP id o2so5539167lfu.13; Wed, 13 Apr 2022 13:28:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CujCbp/sw+khaMiFxer85R28JC7xz+rn3pwqBuSA5a8=; b=wVcKQz7+i2gNvbzEiVQkU2NOM4klnbSiX/bfk5JhEKW3CCdAjlbMyjjMP+iqL5JcsV YRx/BNBxpMmvxgUR9CMfeeWnKk65RQyv/lt7nLolMeLNt4u0DU2Jhsfb3TIhs2j/wUZS VY1L6ToAHG7szUuMereHc1ReEUiosX+UlermqwsGC6QTtcdiPlYuAip11Y94PNeDNyQ0 EbLrdy/MekVoxTUIIdR2K6gRpv3ZlNaK8sUQoIys9a21x4+7Y/5sgTsf3pzYsu8ysIdr Bgur+Jh9KetwPJTTVocX9zcqgX+5OKy0VYzezyjjWMTDN3/Gon06f5+Ccn0HQ6pvutLl CLww== X-Gm-Message-State: AOAM532ezeD7xv8vENRk3k0AFPaa6wR+ZNk7VWCGg8lJrlnVcwUw9uoU EnMR+Hq9bZF+/VsuH7Bbe1LDpPXDsKwyb2BMBkQ= X-Received: by 2002:a05:6512:3404:b0:44a:310f:72f7 with SMTP id i4-20020a056512340400b0044a310f72f7mr31031455lfr.47.1649881712413; Wed, 13 Apr 2022 13:28:32 -0700 (PDT) MIME-Version: 1.0 References: <20220412154817.2728324-1-irogers@google.com> In-Reply-To: From: Namhyung Kim Date: Wed, 13 Apr 2022 13:28:21 -0700 Message-ID: Subject: Re: [PATCH v2 0/4] Tidy up symbol end fixup To: Ian Rogers Cc: John Garry , Will Deacon , Mathieu Poirier , Leo Yan , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , James Clark , Alexandre Truong , German Gomez , Dave Marchevsky , Song Liu , Ravi Bangoria , Li Huafei , =?UTF-8?Q?Martin_Li=C5=A1ka?= , William Cohen , Riccardo Mancini , Masami Hiramatsu , Thomas Richter , Lexi Shao , Remi Bernon , Michael Petlan , Denis Nikitin , linux-arm-kernel@lists.infradead.org, linux-perf-users , linux-kernel , Stephane Eranian Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 12, 2022 at 4:48 PM Ian Rogers wrote: > > On Tue, Apr 12, 2022 at 3:12 PM Namhyung Kim wrote: > > > > Hi Ian, > > > > On Tue, Apr 12, 2022 at 08:48:13AM -0700, Ian Rogers wrote: > > > Fixing up more symbol ends as introduced in: > > > https://lore.kernel.org/lkml/20220317135536.805-1-mpetlan@redhat.com/ > > > caused perf annotate to run into memory limits - every symbol holds > > > all the disassembled code in the annotation, and so making symbols > > > ends further away dramatically increased memory usage (40MB to > > > >1GB). Modify the symbol end logic so that special kernel cases aren't > > > applied in the common case. > > > > > > v2. Drops a merged patch. Fixes a build issue with libbfd enabled. > > > > How about just like this? We can get rid of arch functions as they > > mostly do the same thing (kernel vs module boundary check). > > > > Not tested. ;-) > > > > Thanks, > > Namhyung > > > > --------------8<------------- > > > > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c > > index dea0fc495185..df41d7266d91 100644 > > --- a/tools/perf/util/symbol.c > > +++ b/tools/perf/util/symbol.c > > @@ -35,6 +35,7 @@ > > #include "path.h" > > #include > > #include > > +#include // page_size > > > > #include > > #include > > @@ -231,8 +226,16 @@ void symbols__fixup_end(struct rb_root_cached *symbols) > > prev = curr; > > curr = rb_entry(nd, struct symbol, rb_node); > > > > - if (prev->end == prev->start || prev->end != curr->start) > > - arch__symbols__fixup_end(prev, curr); > > + if (prev->end == prev->start) { > > + /* Last kernel symbol mapped to end of page */ > > I like the simpler logic but don't like applying this in symbol-elf > given the comment says it is kernel specific - so we could keep the > is_kernel change. I'm fine with the change. :) > > > + if (!strchr(prev->name, '[') != !strchr(curr->name, '[')) > > I find this condition not to be intention revealing. On ARM there is > also an || for the condition reversed. When this is in an is_kernel > block then I think it is clear this is kernel hack, so I think it is > good to comment on what the condition is for. Yeah, usually modules are loaded after the kernel image but it seems ARM could load them before the kernel. So I made the change not to call strchr() again. But we might need to consider the special "[__builtin_kprobes]" symbols. > > > + prev->end = roundup(prev->end + 1, page_size); > > Currently the roundup varies per architecture, but it is not clear to > me that it matters. Yeah, it would be the same as the logic for the last entry to be more conservative. > > > + else > > I think we should comment here that we're extending zero sized symbols > to the start of the next symbol. Sounds good. Thanks, Namhyung > > > + prev->end = curr->start; > > + > > + pr_debug4("%s sym:%s end:%#" PRIx64 "\n", > > + __func__, prev->name, prev->end); > > + } > > Thanks, > Ian > > > } > > > > /* Last entry */