lkml.org 
[lkml]   [2020]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 6/6] perf test: Add pmu-events test
From
Date
>>
>> A sample run is as follows for x86:
>>
>> Couldn't bump rlimit(MEMLOCK), failures may take place when creating BPF maps, etc
>> 10: PMU event aliases :
>> --- start ---
>> test child forked, pid 30869
>> Using CPUID GenuineIntel-6-9E-9
>> intel_pt default config: tsc,mtc,mtc_period=3,psb_period=3,pt,branch
>> skipping testing PMU software
>> testing PMU power: skip
>> testing PMU cpu: matched event segment_reg_loads.any
>> testing PMU cpu: matched event dispatch_blocked.any
>> testing PMU cpu: matched event eist_trans
>> testing PMU cpu: matched event bp_l1_btb_correct
>> testing PMU cpu: matched event bp_l2_btb_correct
>> testing PMU cpu: pass
>> testing PMU cstate_core: skip
>> testing PMU uncore_cbox_2: matched event unc_cbo_xsnp_response.miss_eviction
>> testing PMU uncore_cbox_2: pass
>> skipping testing PMU breakpoint
>> testing PMU uncore_cbox_0: matched event unc_cbo_xsnp_response.miss_eviction
>> testing PMU uncore_cbox_0: pass
>> skipping testing PMU tracepoint
>> testing PMU cstate_pkg: skip
>> testing PMU uncore_arb: skip
>> testing PMU msr: skip
>> testing PMU uncore_cbox_3: matched event unc_cbo_xsnp_response.miss_eviction
>> testing PMU uncore_cbox_3: pass
>> testing PMU intel_pt: skip
>> testing PMU uncore_cbox_1: matched event unc_cbo_xsnp_response.miss_eviction
>> testing PMU uncore_cbox_1: pass
>> test child finished with 0
>> ---- end ----
>> PMU event aliases: Ok
>
> SNIP
>
>> +int test__pmu_event_aliases(struct test *test __maybe_unused,
>> + int subtest __maybe_unused)
>> +{
>> + struct perf_pmu *pmu = NULL;
>> +
>> + while ((pmu = perf_pmu__scan(pmu)) != NULL) {
>> + int count = 0;
>

Hi jirka,

> I don't follow the pmu iteration in here.. I'd expect
> we create 'test' pmu

well, that's what we do next in the call to __test__pmu_event_aliases():

static int __test__pmu_event_aliases(char *pmu_name, int *count)
{
struct perf_pmu_alias *alias;
struct perf_pmu *pmu;
LIST_HEAD(aliases);
int res = 0;

pmu = zalloc(sizeof(*pmu));
if (!pmu)
return -1;

pmu->name = pmu_name;

pmu_add_cpu_aliases_map(&aliases, pmu, &pmu_events_map_test);


Here we clone the HW PMU, create the aliases, and verify them against a
known, expected list.

and check that all the aliasses
> are in place as we expect them.. why do we match them
> to existing events?

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

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

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.

Thanks,
John

\
 
 \ /
  Last update: 2020-03-09 11:12    [W:0.067 / U:1.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site