[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4ee55996-e294-c1be-a81b-981e62478f2c@amd.com>
Date: Wed, 14 Jun 2023 09:28:10 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Ian Rogers <irogers@...gle.com>
Cc: acme@...nel.org, jolsa@...nel.org, namhyung@...nel.org,
mark.rutland@....com, peterz@...radead.org,
adrian.hunter@...el.com, kan.liang@...ux.intel.com,
james.clark@....com, alisaidi@...zon.com, leo.yan@...aro.org,
maddy@...ux.ibm.com, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, sandipan.das@....com,
ananth.narayan@....com, santosh.shukla@....com,
Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [PATCH 4/4] perf mem amd: Scan all PMUs instead of just core ones
>> @@ -165,7 +173,7 @@ static void perf_mem_events__print_unsupport_hybrid(struct perf_mem_event *e,
>> char sysfs_name[100];
>> struct perf_pmu *pmu = NULL;
>>
>> - while ((pmu = perf_pmus__scan_core(pmu)) != NULL) {
>> + while ((pmu = perf_mem_scan_next_pmu(pmu)) != NULL) {
>
> It was my mistake to optimize this,
Not really. I mean, there was already a bug which just got exacerbated.
> I think we can just go back to:
> perf_pmus__scan(pmu)
> which would remove a lot of the weak/macros etc. here. We can have a
> comment as to why this is scan not scan_core, because of AMD. I plan
> to further improve overhead of PMUs so I'm not worried about losing
> the small performance win from this.
Sure. Let me do that.
Thanks,
Ravi
Powered by blists - more mailing lists