[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1105240212590.28546@cl320.eecs.utk.edu>
Date: Tue, 24 May 2011 02:20:57 -0400 (EDT)
From: Vince Weaver <vweaver1@...s.utk.edu>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc: linux-kernel@...r.kernel.org, fbuihuu@...il.com, mingo@...e.hu,
paulus@...ba.org, acme@...hat.com
Subject: Re: perf: regression with PERF_EVENT_IOC_REFRESH
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).
Vince
View attachment "sampled_notleader_refresh.c" of type "TEXT/x-csrc" (3040 bytes)
Powered by blists - more mailing lists