[lttng-dev] UST improvement ideas

[David Goulet]

Hello LTTng!

Yes, I'm not involved in development anymore BUT that does not mean I'm
not using LTTng :).

Let me share with all of you some improvement ideas for LTTng-UST after
using it a bit more extensively in a large application. In a nutshell,
we use LTTng to do measurements of certain subsystem of the application
to come up with a performance baseline. With this, we can notice
regressions and also measure improvements. We also use it to identify
unexpected behaviors for some use cases of which we know the expected
behavior.

Here it is:

1) Having a way to use counters in the trace.

So basically, lots of our measurements are based on timing things which
tracepoints are really useful for that but we also gather stuff like
"How many elements seen of an object in the past hour?". It's doable
with tracepoint but when the number goes up to millions quickly, it does
not really scale to have a million tp for one single counter.

The rough idea is this:

	[...]
	tracepoint_counter_inc(mycomponent, mycounter, n);
	[...]

where "n" is the amount to increment the counter designated by
mycomponent:mycounter.

When the buffers are flushed or/and the tracing stop, this counter could
simply be updated in the trace and, for instance, babeltrace could print
them at the beginning of the output.

Also, inspired by Julien Desfossez latency tracker,
https://github.com/jdesfossez/latency_tracker, having a facility for
that in UST would be amazing. A way to say "ok call this TP if this
value reaches X" would be extremely useful. Basically, an easy way to do
sampling in user space with LTTng. For multithreaded application, it
seems to me that it makes sense to use the awesomness of UST thread
safety to gather counters.

2) By default, adding the PID context is really a must I think for
usability. As soon as we have two different PID with the same procname,
the trace is useless without that PID attached to the event.

3) I really think liblttng-ust-fork should be used by default somehow in
lttng-ust. As soon as the application goes in daemon mode, we lose UST
which seems a bit weird. I understand the mechanics why lttng does that
but still I think it can be hackable to make it by default for
usability.

For instance, with a python launcher that does that, UST will bail out.

	subprocess.Popen(["app", "opt1", "opt2", "--daemon"])


My two cents! I think the above would greatly improve UST usability and
make the user happier. I would be happy to open issue on the tracker if
the above make sense :).

Cheers!
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20141125/56f4ca55/attachment.sig>