[lkml]   [2011]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)
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.



 \ /
  Last update: 2011-12-21 01:09    [W:0.104 / U:0.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site