[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM9d7cizsTGrQKDaJnFFXUXmTHCQSzj=+mK2P_ek0Hw1JrF2TQ@mail.gmail.com>
Date: Tue, 27 Oct 2020 13:45:43 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Andi Kleen <ak@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...nel.org>,
Mark Rutland <mark.rutland@....com>,
LKML <linux-kernel@...r.kernel.org>,
Stephane Eranian <eranian@...gle.com>,
Ian Rogers <irogers@...gle.com>
Subject: Re: [RFC] perf evlist: Warn if event group has mixed sw/hw events
Hi,
On Tue, Oct 27, 2020 at 12:49 AM Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
>
> Andi Kleen <ak@...ux.intel.com> writes:
>
> > On Mon, Oct 26, 2020 at 11:19:37PM +0900, Namhyung Kim wrote:
> >> This patch just added a warning before running it. I'd really want to
> >> fix the kernel if possible but don't have a good idea. Thoughts?
> >
> > The easiest fix would be some multi threading in perf stat opening, then then
> > extra latencies could be mostly hidden. One thread per group would probably
> > be overkill, but just a few threads would lower the penalty significantly.
> >
> > I think that would be better than this patch and it's likely not that much
> > more complicated, as this is already a lot of code.
> >
> >> +{
> >> + const char *known_sw_pmu[] = {
> >> + "software", "tracepoint", "breakpoint", "kprobe", "uprobe", "msr"
> >
> > That's a non scalable approach. New pmus get added regularly. It would be better to
> > indicate this in a generic way from the kernel.
>
> That, and also, intel_pt is a software PMU and a few of its features
> depend on intel_pt/.../ being a group leader.
Thanks for the info, that's good to know.
So do you mean intel_pt requires other HW events in the same group?
Thanks
Namhyung
Powered by blists - more mailing lists