[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1705311658490.24977@pianoman.cluster.toy>
Date: Wed, 31 May 2017 17:08:59 -0400 (EDT)
From: Vince Weaver <vince@...ter.net>
To: Peter Zijlstra <peterz@...radead.org>
cc: Andi Kleen <ak@...ux.intel.com>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Stephane Eranian <eranian@...gle.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...nel.org>
Subject: Re: perf group read for inherited events
On Tue, 30 May 2017, Peter Zijlstra wrote:
> On Tue, May 30, 2017 at 01:55:33PM -0400, Vince Weaver wrote:
> > So the issue is currently if you were sampling, and you were sampling on
> > an event group, and you had set PERF_SAMPLE_READ to get all counts for a
> > group, and the event was also inherited....
>
> No, anything PERF_SAMPLE_READ (group or not) on inherited events is
> wrong.
ah, yes. I should fix the wording in the manpage as it's a bit confusing.
> > perf_event_open() would let
> > you do this even though the results would probably be wrong?
>
> Right, currently we have the filter on PERF_FORMAT_GROUP, but it should
> be PERF_SAMPLE_READ.
>
> So a !group SAMPLE_READ on inherited is currently allowed but returns
> 'interesting' values.
I'm not aware of anything that will break on fixing this.
Especially if we are always returning bad results then it would be better
to break things so we find people (if any) who are depending on the wrong
results.
Vince
Powered by blists - more mailing lists