Re: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)

[Joerg Roedel <joro@8bytes.org>]

On Tue, Dec 20, 2011 at 07:40:04PM +0100, Ingo Molnar wrote:

> > I am fine with integrating LWP into perf as long as it makes 
> > sense and does not break the intended usage scenario for LWP.
> 
> That's the wrong way around - in reality we'll integrate LWP 
> upstream only once it makes sense and works well with the 
> primary instrumentation abstraction we have in the kernel.

I still don't see why you want an abstraction for a hardware feature
that clearly doesn't need it. From an enablement perspective LWP is much
closer to AVX than to the MSR based PMU. And nobody really wants or
needs a kernel abstraction for AVX, no?

> Me or PeterZ could just say "this feature is too limited and not 
> convincing enough yet, sorry".

This statement shows very clearly the bottom-line of our conflict. You
see this as a perf-topic, for everyone else it is an x86 topic.

> But i'm being nice and helpful here [...]

And I appreciate the discussion. But we have fundamentally different
stand-points.  I hope we can come to an agreement.

> There's no "security implications" whatsoever. LWP is a ring-3 
> hw feature and it can do nothing that the user-space app could 
> not already do ...

Really? How could an application count DCache misses today without
instrumentation? I guess your answer is 'with perf', but LWP is a much
more light-weight way to do that because it works _completly_ in
hardware when the kernel supports context-switching it.

> 
> > [...] It also destroys the intended use-case for LWP because 
> > it disturbs any process that is doing self-profiling with LWP.
> 
> Why would it destroy that? Self-profiling can install events 
> just fine, the kernel will arbitrate the resource.

Because you can't reliably hand over the LWPCB management to the kernel.
The instruction to load a new LWPCB is executable in ring-3. Any
kernel-use of LWP will never be reliable. 

> > So what you are saying is (not just here, also in other emails 
> > in this thread) that every hardware not designed for perf is 
> > crap?
> 
> No - PMU hardware designed to not allow the profiling of the 
> kernel is obviously a crappy aspect of it. Also, PMU hardware 
> that does not allow 100% encapsulation by the kernel is 
> obviously not very wisely done either.

Why? Whats wrong with user-space having control over its own PMU in a
safe way? This is what the feature was designed for.


Thanks,

	Joerg