LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: <peterz@infradead.org>, <mingo@redhat.com>, <acme@kernel.org>,
	<mark.rutland@arm.com>, <alexander.shishkin@linux.intel.com>,
	<namhyung@kernel.org>, <will@kernel.org>, <ak@linux.intel.com>,
	<linuxarm@huawei.com>, <linux-kernel@vger.kernel.org>,
	<james.clark@arm.com>, <qiangqing.zhang@nxp.com>
Subject: Re: [PATCH 6/6] perf test: Add pmu-events test
Date: Mon, 9 Mar 2020 16:20:52 +0000	[thread overview]
Message-ID: <6691dd26-7c53-26f0-b583-131707ede608@huawei.com> (raw)
In-Reply-To: <20200309152635.GD67774@krava>

>>
>> The events in test_cpu_aliases[] or test_uncore_aliases[] are checked
>> against the events from pmu-events/arch/test/test_cpu/*.json
> 

Hi Jirka,

> I don't understand the benefit of this.. so IIUC:
> 
>    - jevents will go through arch/test and populate pmu-events/pmu-events.c
>      with:
>         struct pmu_event pme_test_cpu[] ...
>         struct pmu_events_map pmu_events_map_test ...

Right. And the idea is that pme_test_cpu[] can be used as generic set of 
events for testing on any arch/cpuid. (note: I'll just ignore uncore 
events for the moment)

> 
>    - so we actualy have the parsed json events in C structs and we can go
>      through them and check it contains fields with strings that we expect

No, we use pme_test_cpu[] to generate the event aliases for a PMU, and 
verify that the aliases are as expected.

> 
>    - you go through all detected pmus and check if the tests events we
>      generated are matching some of the events from these pmus,

Not exactly.

>      and that's where I'm lost ;-) why?

So consider the "cpu" HW PMU. During normal operation, we create the 
event aliases for this PMU in pmu_lookup()->pmu_add_cpu_aliases(). This 
step looks up a map of cpu events for that CPUID, and then creates the 
event aliases for that PMU from that map.

I want the test to recreate this and verify that the events from the 
test JSONs will have event aliases created properly.

So in the test when we scan the PMUs and find "cpu" HW PMU, we create a 
test PMU with the same name, create the event aliases from 
pme_test_cpu[] for that test PMU, and then verify that the event aliases 
created are as expected. Then the test PMU is deleted.

So overall the test covers:
a. jevents code to generate the struct pmu_event []
b. util/pmu.c code to create the event aliases for a given PMU

Note: the test does not (yet) cover matching of events declared in the 
HW PMU sysfs folder. I'm talking about these, for example:

$ ls /sys/bus/event_source/devices/cpu/events/
branch-instructions  cache-references  el-abort     el-start 
ref-cycles     ...

> 
>>
>>>
>>> or as I'm thinking about that now, would it be enough
>>> to check pme_test_cpu array to have string that we
>>> expect?
>>
>> Right, I might change this.
>>
>> So currently we iterate the PMU aliases to ensure that we have a matching
>> event in pme_test_cpu[]. It may be better to iterate the events in
>> pme_test_cpu[] to ensure that we have an alias.
> 
> that's what I described above.. I dont understand the connection/value
> of this tests
> 
>>
>> The problem here is uncore PMUs. They have the "Unit" field, which is used
>> for matching the PMU. So we cannot ensure test events from uncore.json will
>> always have an event alias created per PMU. But maybe I could use
>> pmu_uncore_alias_match() to check if the test event matches in this case.
> 
> hum I guess I don't follow all the details.. but some more explanation
> of the test would be great

Let's just concentrate on core PMU ATM :)

Thanks,
John

  reply	other threads:[~2020-03-09 16:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 11:08 [PATCH 0/6] perf test pmu-events case John Garry
2020-03-05 11:08 ` [PATCH 1/6] perf jevents: Fix leak of mapfile memory John Garry
2020-03-05 15:13   ` Arnaldo Carvalho de Melo
2020-03-07  7:36   ` [tip: perf/urgent] " tip-bot2 for John Garry
2020-03-05 11:08 ` [PATCH 2/6] perf jevents: Support test events folder John Garry
2020-03-05 11:08 ` [PATCH 3/6] perf jevents: Add some test events John Garry
2020-03-05 11:08 ` [PATCH 4/6] perf pmu: Refactor pmu_add_cpu_aliases() John Garry
2020-03-05 11:08 ` [PATCH 5/6] perf pmu: Add is_pmu_core() John Garry
2020-03-05 11:08 ` [PATCH 6/6] perf test: Add pmu-events test John Garry
2020-03-09  8:49   ` Jiri Olsa
2020-03-09 10:12     ` John Garry
2020-03-09 15:26       ` Jiri Olsa
2020-03-09 16:20         ` John Garry [this message]
2020-03-13 10:32           ` Jiri Olsa
2020-03-13 11:08             ` John Garry

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=6691dd26-7c53-26f0-b583-131707ede608@huawei.com \
    --to=john.garry@huawei.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qiangqing.zhang@nxp.com \
    --cc=will@kernel.org \
    --subject='Re: [PATCH 6/6] perf test: Add pmu-events test' \
    /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

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).