Re: [tip:perf/core] tools/perf: Add required memory barriers

[Vince Weaver]

On Wed, 6 Nov 2013, Peter Zijlstra wrote:

> On Wed, Nov 06, 2013 at 03:00:11PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2013 at 08:50:47AM -0500, Vince Weaver wrote:
> > 
> > > remember that there are users trying to use this outside of the kernel 
> > > where we don't necessarily have access to internal kernl macros.  Some of 
> > > these users aren't necessarily GPLv2 compatible either (PAPI for example 
> > > is more or less BSD licensed) so just cutting and pasting chunks of 
> > > internal kernel macros isn't always the best route either.
> > 
> > Other license stuff is not my problem; that said I doubt there's much
> > copyright to claim on a volatile cast.

perhaps, but everytime some internal kernel stuff goes into the visible 
API it makes it harder to use.  I don't think most other system calls leak 
kernel interfaces like this.

It's also an issue because people build PAPI with non-gcc compilers like 
Intel and clang so there's no guarantee kernel macro tricks are going to 
work for everyone.

Having perf in the kernel tree really makes it hard for you guys to keep a 
clean API/ABI it seems.

> Also, does PAPI actually use the buffer then? I thought that was
> strictly self monitoring.

PAPI has always supported a simplistic sampling mode, where you 
enable a one-shot overflow signal handler to be triggered after X events, 
and then read out the instruction pointer from the mmap buffer.  Then 
usually you re-enable for the next sample.  (You may dimly remember this 
because this usage style is very different than perf's so it breaks often 
w/o anyone but us noticing).

Not very effective and not taking full advantage of all perf_event has to 
support, but it's a cross-platform legacy interface supported easily by 
most implementations.

We've been planning to do a proper sampled perf_event interface but it's 
been hard trying to hammer out a clean interface that fits well with the 
existing PAPI design.

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/