Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp2385755rdg; Mon, 16 Oct 2023 02:51:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE3/tTInpP9DowdfesmA9X7751vryni1QmG+ysp53jUa0mdGOXBAQEVnyZInRzX+pW5K4kC X-Received: by 2002:a17:902:f092:b0:1c9:d667:4e77 with SMTP id p18-20020a170902f09200b001c9d6674e77mr9338634pla.65.1697449886484; Mon, 16 Oct 2023 02:51:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697449886; cv=none; d=google.com; s=arc-20160816; b=mNSrv8pGGgvutFFXTxLKfsmeSi1BYqoRnA6DPoaeRSsQLoHE8K3EQBhLSH7d1VEq+c 5hF96IYa5xzgCbjPfnCefIhrYkLroc9p+f/zqzyBBGrz8/rJg8J1iq0uk2zCUdSGqqGD TdZ3tgXiNEbtmWebhr+i5D6twvfi5DPhw5CTQ9hobX7e3WubPdGtBBMKIzerH3ztmLAg pDw1eqG6tDBm1TU8rwbXEiQ6lsZdTdtBXN6ObZbSem5KPjwvv4Id3TWRgBbeLB2qqMpw 6kDQxgaHgJoW6rNRzhOiOioY4vwT+DGpwaF4xxi8KPyWx0BDYsCw4zO5OcYWzRWfLF8I RMOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject; bh=bUGyISA9uHHUSOBxkW4qtTCPEeeDnHlSHmMcvaOpfTA=; fh=nT2wTZgXEMIxp+FtTDyH16GzTOUAWXhJhssHDYMKbso=; b=T5yiDRhZ7c7Oc1PYW3oRnTFfJWvWduOsDtTKa0KzF4mRgq44csP3bxzqs56SluwlsW fHJoShFlRN5pZlfZ9Hgi+5+BMT49yPyyD9m0MUPOKvC/L4c41bjJ7Ym4jE7n1h+C5fte JhaENR5ERQCJIcfQLV55Yi/Mi5Qb16OktqLW0GAfi2yu35DEXAnrI9RsEeJ0Qds579vj htMNO4hN9MBVJSzp23uR0lI5Dlu5y6RH4advf8OtOgQolgUxakPqN0KBmsk6Q3vVYDYX ryaQb5jEjCqvFKvi9wBeuc8o35PtICrS9q9KGsp9dSxi06WbFlgOqLEVscQhxgfJePE5 hnyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id h9-20020a170902f54900b001bda57935fasi6135815plf.64.2023.10.16.02.51.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 02:51:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 80380804C213; Mon, 16 Oct 2023 02:50:34 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229459AbjJPJuU (ORCPT + 99 others); Mon, 16 Oct 2023 05:50:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230152AbjJPJuT (ORCPT ); Mon, 16 Oct 2023 05:50:19 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E93AB4; Mon, 16 Oct 2023 02:50:16 -0700 (PDT) Received: from kwepemm000003.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4S8C09669BzvPxM; Mon, 16 Oct 2023 17:45:29 +0800 (CST) Received: from [10.67.111.205] (10.67.111.205) by kwepemm000003.china.huawei.com (7.193.23.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 16 Oct 2023 17:50:11 +0800 Subject: Re: [PATCH v2 6/7] perf pmu-events: Remember the perf_events_map for a PMU To: Ian Rogers , Suzuki K Poulose , Mike Leach , James Clark , Leo Yan , John Garry , Will Deacon , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Adrian Hunter , Thomas Richter , Ravi Bangoria , Kajol Jain , Jing Zhang , Kan Liang , , , , References: <20231012175645.1849503-1-irogers@google.com> <20231012175645.1849503-7-irogers@google.com> From: Yang Jihong Message-ID: Date: Mon, 16 Oct 2023 17:50:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20231012175645.1849503-7-irogers@google.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.111.205] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm000003.china.huawei.com (7.193.23.66) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 16 Oct 2023 02:50:34 -0700 (PDT) Hello, On 2023/10/13 1:56, Ian Rogers wrote: > strcmp_cpuid_str performs regular expression comparisons and so per > CPUID linear searches over the perf_events_map are expensive. Add a > helper function called map_for_pmu that does the search but also > caches the map specific to a PMU. As the PMU may differ, also cache > the CPUID string so that PMUs with the same CPUID string don't require > the linear search and regular expression comparisons. This speeds > loading PMUs as the search is done once per PMU to find the > appropriate tables. > > Signed-off-by: Ian Rogers > --- > tools/perf/pmu-events/jevents.py | 109 ++++++++++++++++++++----------- > 1 file changed, 70 insertions(+), 39 deletions(-) > > diff --git a/tools/perf/pmu-events/jevents.py b/tools/perf/pmu-events/jevents.py > index 96dc74c90b20..3c091ab75305 100755 > --- a/tools/perf/pmu-events/jevents.py > +++ b/tools/perf/pmu-events/jevents.py > @@ -976,68 +976,99 @@ int pmu_metrics_table__for_each_metric(const struct pmu_metrics_table *table, > return 0; > } > > -const struct pmu_events_table *perf_pmu__find_events_table(struct perf_pmu *pmu) > +static const struct pmu_events_map *map_for_pmu(struct perf_pmu *pmu) > { > - const struct pmu_events_table *table = NULL; > - char *cpuid = perf_pmu__getcpuid(pmu); > + static struct { > + const struct pmu_events_map *map; > + struct perf_pmu *pmu; > + } last_result; > + static struct { > + const struct pmu_events_map *map; > + char *cpuid; > + } last_map_search; > + static bool has_last_result, has_last_map_search; > + const struct pmu_events_map *map = NULL; > + char *cpuid = NULL; > size_t i; > > - /* on some platforms which uses cpus map, cpuid can be NULL for > + if (has_last_result && last_result.pmu == pmu) > + return last_result.map; > + > + cpuid = perf_pmu__getcpuid(pmu); For the software pmu, we do not need to look for the events table. It seems that the software pmu can be filtered out in perf_pmu__lookup() to reduce unnecessary perf_pmu__find_events_table() calls. I tried to submit a patch, please see if it helps: https://lore.kernel.org/all/20231016093309.726436-1-yangjihong1@huawei.com/ Thanks, Yang