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

From: Vince Weaver <vince@deater.net>
To: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	hpa@zytor.com, anton@samba.org, mathieu.desnoyers@polymtl.ca,
	linux-kernel@vger.kernel.org, michael@ellerman.id.au,
	paulmck@linux.vnet.ibm.com, benh@kernel.crashing.org,
	fweisbec@gmail.com, VICTORK@il.ibm.com, tglx@linutronix.de,
	oleg@redhat.com, mikey@neuling.org,
	linux-tip-commits@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	David Ahern <dsahern@gmail.com>
Subject: Re: [tip:perf/core] tools/perf: Add required memory barriers
Date: Thu, 7 Nov 2013 09:27:54 -0500 (EST)	[thread overview]
Message-ID: <alpine.DEB.2.02.1311070918440.19262@pianoman.cluster.toy> (raw)
In-Reply-To: <20131107082122.GC32438@gmail.com>

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.

Vince