> -----Original Message----- > From: Robin Murphy [mailto:[email protected]] > Sent: 02 October 2018 17:35 > To: Jean-Philippe Brucker <[email protected]>; Shameerali > Kolothum Thodi <[email protected]>; > [email protected] > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; John Garry > <[email protected]>; [email protected]; [email protected]; > Linuxarm <[email protected]>; [email protected]; linux-arm- > [email protected]; Guohanjun (Hanjun Guo) > <[email protected]>; [email protected] > Subject: Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver > > On 02/10/18 17:19, Jean-Philippe Brucker wrote: > > On 02/10/2018 15:11, Jean-Philippe Brucker wrote: > >>> + cfgr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_CFGR); > > > > Something I missed previously: when SMMU_PMCG_CFGR.SID_FILTER_TYPE > is 1, > > filtering for all counters is configured by SMMU_PMCG_SMR0 and > > SMMU_PMCG_EVTYPER0 (instead of having one separate filter per counter). > > Oh, I hadn't even noticed it had that mode as well...
Thanks Jean. Missed that completely. > > In that mode with your patch, if the user applies a filter to the first > > event in the list passed to perf, it will be applied to all events. > > Filter applied on any subsequent event will be ignored. Could we make > > this more explicit? Maybe in the probe print that the PMCG is > > global-filtering, and when attempting to apply a filter to something > > else than EVCNTR0, return an error? > > FWIW filtering is always per-counter-group on the SMMUv2 PMU, and it's > actually pretty straightforward to cope with - pmu->add() just needs to > reject the event if one with an incompatible configuration is already > scheduled, so perf core handles it much like having more events than > counters, by rotating the mutually-exclusive sets. I will take a look and address this in next version. Thanks, Shameer
