Re: [patch] trace: Add user-space event tracing/injection

[Peter Zijlstra <peterz@infradead.org>]

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.