[lttng-dev] Questions about LTTNG_UST_REGISTER_TIMEOUT

[Jérémie Galarneau]

On Fri, Jul 26, 2013 at 3:29 PM, Martin Ünsal <martinunsal at gmail.com> wrote:
> Hi all,
>
> I am a new lttng-ust user. I would like to leave tracepoints compiled into
> production code. I have verified that inactive tracepoints have extremely
> low overhead, but I am concerned about startup time and
> LTTNG_UST_REGISTER_TIMEOUT. Our typical use case is that we are not tracing
> and there is no lttng-sessiond, we enable tracing only in development or QA.
>
> The specific questions:
>
> 1) What scenarios might the timeout come into play? I have tested with and
> without lttng-sessiond running and I have seen no more than 10ms overhead
> during app startup caused by lttng. That's no problem, but if there is some
> unforeseen scenario where I introduce 3s overhead I am in a world of hurt!
>

This timeout is in place because the applications' registration to the
session daemon may take a long time if a lot of instrumented
applications are launched simultaneously. The only time I see the
launch time affected on the order of seconds, on my development
machine, is when performing stress tests; e.g. launching a couple of
thousands instrumented applications at once. Only you know if that's a
realistic load you may encounter.

> 2) If I set LTTNG_UST_REGISTER_TIMEOUT=0, what scenario would this fail and
> how would it fail? (Silently or detectably?)
>

It will fail if the registration request cannot be served right-away.
The registration failing only means that the events won't be saved. It
should not impact your application in any other way.

I don't know how you could easily detect the registration's outcome
from your application, though... I can certainly see how that would be
useful.

The work-around I can propose is to use the lttng-ctl API to probe the
session daemon from your application. You could use the
lttng_list_sessions(), lttng_list_channels() and lttng_list_events()
functions to check all enabled events for your application's PID.

Have a look at the "lttng.h" header (lttng-tools) and let me know if
you need further clarifications.

> Actually I think these are more or less the same question viewed from two
> different angles.
>
> Thanks much. BTW I should say, I've been doing coordinated userspace and
> kernel tracing for performance issues in Linux for many, many years using a
> variety of homegrown tools and LTTng is fantastic, just the right feature
> set and excellent performance. It's what I wish I'd built. :)

We're always looking for contributors! :-)

Regards,
Jérémie

>
> Martin
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com