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

From: Vince Weaver
Date: Thu Nov 07 2013 - 09:26:08 EST

On Thu, 7 Nov 2013, Ingo Molnar wrote:

> I don't want a library that is external and under-tested: for example
> quite a few of the PAPI breakages were found very late, after a new kernel
> has been released - that's the big disadvantage of librarization and
> decentralization. The decentralized library model might work if all you
> want to create is a second-class also-ran GUI, but it just doesn't work
> very well for actively developed kernel code.

I would argue that PAPI's problem was because it was trying to use
perf_event_open() which is a complex, poorly documented kernel interface
with a lot of code churn. Usually it's the job of the kernel not to break
user-space, not the other way around.

It's too late on the decentralized library issue. PAPI has to support
kernels going back to 2.6.32 so it's going to have its own copy of the
mmap parsing code even if a new syscall gets introduced.

There are a lot of tools out there now that open-code a perf_event
interface. I don't think it's really possible to say "anyone using
the syscall without using our kernel library is unsupported".

This current issue with the locking doesn't really matter much because as
far as I can tell it's an obscure potential corner case that no one has
seen in practice yet. So the easiest solution might just be to ignore the
whole issue, which is a lot easier than trying to write a custom portable
cross-platform license-agnostic memory barrier library.

We do try to keep the papi mmap reading code as close to perf's as
possible though just because we know you aren't going to notice or care if
you break it for other users.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at