lkml.org 
[lkml]   [2011]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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.


    Thanks,

    Joerg



    \
     
     \ /
      Last update: 2011-12-21 01:09    [W:0.026 / U:29.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site