From: John Garry <john.garry@huawei.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Ian Rogers <irogers@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Jin Yao <yao.jin@linux.intel.com>, Leo Yan <leo.yan@linaro.org>,
Kan Liang <kan.liang@linux.intel.com>,
Kajol Jain <kjain@linux.ibm.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Paul Clarke <pc@us.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 2/2] perf test: Improve pmu event metric testing
Date: Fri, 15 May 2020 15:36:44 +0100 [thread overview]
Message-ID: <6a7f8e76-981e-0a84-0043-262c0e2d00d1@huawei.com> (raw)
In-Reply-To: <20200515114827.GA3547844@krava>
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 <john.garry@huawei.com> 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
next prev parent reply other threads:[~2020-05-15 14:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 6:22 [PATCH 1/2] perf expr: Test parsing of floating point numbers Ian Rogers
2020-05-13 6:22 ` [PATCH 2/2] perf test: Improve pmu event metric testing Ian Rogers
2020-05-13 6:29 ` Ian Rogers
2020-05-13 15:25 ` John Garry
2020-05-13 16:10 ` Ian Rogers
2020-05-14 8:59 ` John Garry
2020-05-14 23:02 ` Ian Rogers
2020-05-15 9:09 ` John Garry
2020-05-15 11:48 ` Jiri Olsa
2020-05-15 14:36 ` John Garry [this message]
2020-05-13 17:48 ` Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a7f8e76-981e-0a84-0043-262c0e2d00d1@huawei.com \
--to=john.garry@huawei.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pc@us.ibm.com \
--cc=peterz@infradead.org \
--cc=yao.jin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).