[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230313142156.GL2017917@hirez.programming.kicks-ass.net>
Date: Mon, 13 Mar 2023 15:21:56 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: namhyung@...nel.org, eranian@...gle.com, acme@...nel.org,
mark.rutland@....com, jolsa@...nel.org, irogers@...gle.com,
bp@...en8.de, x86@...nel.org, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, sandipan.das@....com,
ananth.narayan@....com, santosh.shukla@....com
Subject: Re: [PATCH v2 2/3] perf/ibs: Fix interface via core pmu events
On Mon, Mar 13, 2023 at 05:59:46PM +0530, Ravi Bangoria wrote:
> > Now, we already have a gruesome hack in there, and I'm thikning you
> > should use that instead of adding yet another one. Note:
> >
> > if (ret == -ENOENT && event->attr.type != type && !extended_type) {
> > type = event->attr.type;
> > goto again;
> >
> > So if you have amd_pmu_hw_config() do:
> >
> > event->attr.type = ibs_pmu.type;
> > return -ENOENT;
> >
> > it should all just work no?
>
> IBS driver needs to convert RAW pmu config to IBS config, which it does
> based on original event->attr.type. See perf_ibs_precise_event(). This
> logic will fail with event->attr.type overwrite.
amd_pmu_hw_config() could also rewrite event->attr.config I suppose.
I don't think we actually use/expose these event->attr fields again
after all this, do wel?
The closest to that is perf_event_modify_attr(), but that is limited to
TYPE_BREAKPOINT for the time being (also, could this be used to cure
your in-kernel IBS usage woes?).
Powered by blists - more mailing lists