Messages in this thread | | | Date | Wed, 17 Nov 2010 14:30:08 +0200 | Subject | Re: [patch] trace: Add user-space event tracing/injection | From | Pekka Enberg <> |
| |
On Wed, Nov 17, 2010 at 2:24 PM, Ingo Molnar <mingo@elte.hu> wrote: > > * Ingo Molnar <mingo@elte.hu> wrote: > >> > Does this concept lend itself to tracing latencies in userspace applications >> > that run in virtual machines (e.g. the Java kind)? I'm of course interested in >> > this because of Jato [1] where bunch of interesting things can cause jitter: JIT >> > compilation, GC, kernel, and the actual application doing something (in either >> > native code or JIT'd code). It's important to be able to measure where >> > "slowness" to desktop applications and certain class of server applications >> > comes from to be able to improve things. >> >> Makes quite a bit of sense. >> >> How about the attached patch? It works fine with the simple testcase included in >> the changelog. There's a common-sense limit on the message size - but otherwise it >> adds support for apps to generate a free-form string trace event. > > The entirely untested Jato patch below adds support for this to Jato's user-space > tracer. Btw., you have _hundreds_ of tracepoints in Jato, wow! > > The prctl() approach is very attractive because it's very simple to integrate. It's > also reasonably fast, there's no fd baggage in prctl(). It is also arguably a > 'process/task event' so fits prctl()'s original design (if it ever had one ...). > > Note, i kept the original Jato buffering as well, and the prctl() does finegrained > events, one event per trace_printf() line printed. > > I think it makes sense to generate a separate event for all trace_printf() calls, > because that way the events propagate immediately. OTOH i dont know how large the > trace messages are - if there's really big tables printed (or lines are constructed > out of many trace_printf() calls) then it may make sense to buffer them a bit.
There's two kinds of tracing: simple (almost) one-liners (e.g. trace_invoke() function) that are similar to trace points and data dumps (e.g. trace_lir() function). I don't think we want too hook the latter to PR_TASK_PERF_USER_TRACE but for the former, it definitely makes tons of sense for the former!
Pekka
| |