From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Vince Weaver <vweaver1@eecs.utk.edu>
Cc: linux-kernel@vger.kernel.org, fbuihuu@gmail.com, mingo@elte.hu,
paulus@samba.org, acme@redhat.com
Subject: Re: perf: regression with PERF_EVENT_IOC_REFRESH
Date: Tue, 24 May 2011 12:30:36 +0200 [thread overview]
Message-ID: <1306233036.2497.15.camel@laptop> (raw)
In-Reply-To: <alpine.DEB.2.00.1105240212590.28546@cl320.eecs.utk.edu>
On Tue, 2011-05-24 at 02:20 -0400, Vince Weaver wrote:
> On Mon, 23 May 2011, Peter Zijlstra wrote:
>
> > > before the changeset, you could have a counter group where only one of the
> > > subevents was sampling. PERF_EVENT_IOC_REFRESH would correctly enable
> > > sampling for only that subevent.
> >
> > But how? it adds to the event_limit of the event you call the ioctl()
> > on, not on any of the group siblings.
>
> the old behavior did.
>
> > > With the changeset applied, this fails with EINVALID. Now you can only
> > > sample in a group leader.
> >
> > I'm not quite seeing how group-leaders are relevant here, you can only
> > call this ioctl() on sampling events, regardless of if they're they
> > group leader or a sibling.
>
> previous behavior was that if you called it on a group leader that wasn't
> sampling, a sibling event that was sampling would be activated.
>
> > > Was this an intended change? It breaks various of our PAPI regression
> > > tests that worked fine before the change was committed.
> >
> > I'm not quite seeing what's wrong yet, the change seemed simple enough
> > in that calling that ioctl() on an event that wasn't capable of
> > generating samples doesn't make sense, since it will increase the event
> > limit for the event you call it on.
>
> attached is some code that will return a sampled count on older kernels
> but gives EINVAL on current kernels.
>
> The old behavior might have been unintentional, but PAPI unfortunately
> depends on it (not code I originaly wrote, but code I have to maintain).
Right, so what the code does is create a group of which the leader is
disabled, which effectively has the whole group disabled. It then abuses
REFRESH,0 to enable the leader.
The code should use ENABLE (surprise, surprise!) to enable the leader
and get things going.
This is very clear abuse of the API and I'm not really inclined to fix
it, in fact, I'd be tempted to add an additional test to verify the
argument to REFRESH > 0.
Then again, I do appreciate you're having a problem there, how soon can
you push this trivial fix into all maintained PAPI branches? We could
revert this for one release and then properly shut this abuse down the
next release.
next prev parent reply other threads:[~2011-05-24 10:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 20:04 perf: regression with PERF_EVENT_IOC_REFRESH Vince Weaver
2011-05-23 20:22 ` Peter Zijlstra
2011-05-24 6:20 ` Vince Weaver
2011-05-24 10:30 ` Peter Zijlstra [this message]
2011-05-24 15:04 ` Vince Weaver
2011-05-24 15:10 ` Peter Zijlstra
2011-05-24 15:40 ` Ingo Molnar
2011-05-24 20:31 ` Vince Weaver
2011-05-25 10:39 ` Ingo Molnar
2011-05-25 21:24 ` Vince Weaver
2011-05-24 17:53 ` Vince Weaver
2011-05-24 15:11 ` Peter Zijlstra
2011-05-24 15:18 ` Peter Zijlstra
2011-05-24 21:48 ` Vince Weaver
2011-05-28 3:38 ` Vince Weaver
2011-05-28 10:22 ` Peter Zijlstra
2011-05-28 13:26 ` perf: definition of a "regression" Vince Weaver
2011-06-02 7:45 ` Ingo Molnar
2011-05-29 16:54 ` perf: regression with PERF_EVENT_IOC_REFRESH Vince Weaver
2011-05-31 1:33 ` perf: [patch] " Vince Weaver
2011-05-31 7:17 ` Peter Zijlstra
2011-05-31 7:23 ` Peter Zijlstra
2011-05-31 13:49 ` Vince Weaver
2011-05-31 15:52 ` Peter Zijlstra
2011-05-31 16:39 ` Vince Weaver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1306233036.2497.15.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=fbuihuu@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=vweaver1@eecs.utk.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox