Re: [PATCH 6/6] perf test: Add pmu-events test

[Jiri Olsa <jolsa@redhat.com>]

On Mon, Mar 09, 2020 at 04:20:52PM +0000, John Garry wrote:
> > > 
> > > 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.

aah ok, my first objective was to have some way to test pmu-events
changes we plan to do and their affect to generated pmu-event.c

you want to test the code paths after that.. perfect

> 
> 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:

ok

> 
> $ 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 :)

ok, thanks,
jirka