lkml.org 
[lkml]   [2010]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] trace: Add user-space event tracing/injection
    From
    Date
    On Wed, 2010-11-17 at 13:58 +0100, Ingo Molnar wrote:
    > * Peter Zijlstra <peterz@infradead.org> wrote:

    > > I don't much like it, Jato already does its own tracing for the anon_vma
    > > symbols, it might as well write its own event log too (would need a
    > > proper VDSO clock thingy though).
    >
    > The problem is that it then does not properly mix with other events outside of the
    > control of the application.
    >
    > For example if there are two apps both generating user events, but there's no
    > connection with them, a system-wide tracer wont get a properly ordered set of events
    > - both apps will trace into their own buffers. So if we have:
    >
    > CPU1
    >
    > app1: "user event X"
    > app2: "user event Y"
    >
    > Then a 'trace --all' system-wide tracing session will not get proper ordering
    > between app1 and app2's events. It only gets timestamps - which may or may not be
    > correct.

    I claim we can do a VDSO to the quality of the kernel/sched_clock.c
    code, which basically means we can do it as good as the kernel can.

    > User-space tracing schemes tend to be clumsy and limiting. There's other
    > disadvantages as well: approaches that expose a named pipe in /tmp or an shmem
    > region are not transparent and robust either: if user-space owns a pending buffer
    > then bugs in the apps can corrupt the trace buffer, can prevent its flushing when
    > the app goes down due to an app bug (and when the trace would be the most useful),
    > etc. etc.

    Sure, but you're not considering the fact that Jato already needs an
    interface to communicate its generated symbols, also writing its own
    events really isn't a big deal after that.

    > Also, in general their deployment isnt particularly fast nor lightweight - while
    > prctl() is available everywhere.

    I know your reasoning, but deployment isn't everything. Technical sanity
    does, I hope, still count for something as well.

    > And when it comes to tracing/instrumentation, if we make deployment too complex,
    > people will simply not use it - and we all use. A prctl() isnt particularly sexy
    > design, but it's a task/process event that we are generating (so related to prctls),
    > plus it's available everywhere and is very easy to deploy.

    Different tools for different people, complex applications like JITs can
    use a more complex interface to communicate all their various data.

    A simple printk() style interface through a syscall (preferably not
    prctl) if fine too, it just doesn't suffice for everything, nor should
    we want it to.


    \
     
     \ /
      Last update: 2010-11-17 14:13    [W:3.335 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site