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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FF1FC433E0 for ; Fri, 15 May 2020 14:37:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A4AE207C4 for ; Fri, 15 May 2020 14:37:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727899AbgEOOhv (ORCPT ); Fri, 15 May 2020 10:37:51 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2214 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727811AbgEOOho (ORCPT ); Fri, 15 May 2020 10:37:44 -0400 Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 89BACFEE6D83198421C0; Fri, 15 May 2020 15:37:42 +0100 (IST) Received: from [127.0.0.1] (10.47.1.24) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Fri, 15 May 2020 15:37:39 +0100 Subject: Re: [PATCH 2/2] perf test: Improve pmu event metric testing To: Jiri Olsa CC: Ian Rogers , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Namhyung Kim , Andi Kleen , Jin Yao , Leo Yan , Kan Liang , Kajol Jain , Adrian Hunter , Paul Clarke , "linux-kernel@vger.kernel.org" , Stephane Eranian References: <20200513062236.854-1-irogers@google.com> <20200513062236.854-2-irogers@google.com> <5264e16c-fb1a-4bbc-96b5-1d867e38902e@huawei.com> <799e8dde-6f56-7add-a177-3e21c0de03fc@huawei.com> <20200515114827.GA3547844@krava> From: John Garry Message-ID: <6a7f8e76-981e-0a84-0043-262c0e2d00d1@huawei.com> Date: Fri, 15 May 2020 15:36:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20200515114827.GA3547844@krava> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.1.24] X-ClientProxiedBy: lhreml709-chm.china.huawei.com (10.201.108.58) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/05/2020 12:48, Jiri Olsa wrote: > On Fri, May 15, 2020 at 10:09:10AM +0100, John Garry wrote: >> On 15/05/2020 00:02, Ian Rogers wrote: >>> On Thu, May 14, 2020 at 2:00 AM John Garry wrote: >>>> >>>> On 13/05/2020 17:10, Ian Rogers wrote: >>>>>> Out of interest, if we could move the validation of metrics to jevents, >>>>>> how much functionality would we still have here? >>>>> If we add checking to jevents then the MetricExpr would be known to be >>>>> valid, however, the events (aka ids) within the expression could be >>>>> invalid. >>>> >>>> So I think that has some value. I mean, just to detect syntax errors, >>>> like those remedied in "perf metrics: fix parse errors in power8 metrics". >>>> >>>>> I'm not sure we could realistically check the events at >>>>> jevents (build) time as there is no guarantee that the machine we run >>>>> on is the same as the one we compile on. >>>> >>>> But we could at least check that there are event aliases for that CPU, >>>> right? (by examining the JSONs for that cpu). If the event alias does >>>> not actually match on the target CPU, then that can't be helped. >>> >>> Agreed, I think there will be some cases where something more can be >>> done. Jiri has proposed fake pmus as well: >>> https://www.spinics.net/lists/linux-perf-users/msg11760.html >>> I don't know how much sense it makes trying to get this in jevents, as >>> long as 'perf test' is run. >> >> At a glance, that does not look like something we would want in jevents. But >> rather the metric expr parsing error detection and alias checking. >> >> About jirka's patch: >> >> --- a/tools/perf/tests/pmu-events.c >> +++ b/tools/perf/tests/pmu-events.c >> @@ -485,6 +485,102 @@ static int test_parsing(void) >> return ret == 0 ? TEST_OK : TEST_SKIP; >> } >> >> + >> +static struct test_metric metrics[] = { >> + { .metric = "imx8_ddr0@read\\-cycles@ * 4 * 4", }, >> + { .metric = "imx8_ddr0@axid\\-read\\,axi_mask\\=0xffff\\,axi_id\\=0x0000@ >> * 4", }, >> + { .metric = "(cstate_pkg@c2\\-residency@ / msr@tsc@) * 100", }, >> + { .metric = "(imx8_ddr0@read\\-cycles@ + imx8_ddr0@write\\-cycles@)", }, >> +}; >> >> Maybe we could add these to pmu-events/arch/test/test_cpu/metric.json, and >> get at them that way. > > that test sets the 'fake pmu' stuff.. could we do that in your test? I'm not sure about a test comparable to the alias match testing, but at least it should be possible to verify that jevents generates as-expected metric events (as done in __test_pmu_event_table() for regular events). Cheers, John