[lttng-dev] What is the size overhead of UST tracepoints? (hint: very large indeed)

[Amit Margalit]

Hi,

Thanks for the suggestions. I am indeed going in a similar direction.

Nonetheless, I still think the we as a community of people who care about 
LTTng itself, should push for improving its memory footprint where 
possible.

Amit Margalit
IBM XIV - Storage Reinvented
XIV-NAS Development Team
Tel. 03-689-7774
Fax. 03-689-7230



From:   Vlad <vlad at demoninsight.com>
To:     lttng-dev <lttng-dev at lists.lttng.org>
Date:   10/29/2013 04:34 PM
Subject:        Re: [lttng-dev] What is the size overhead of UST 
tracepoints?    (hint: very large indeed)




On Oct 29, 2013, at 4:42 AM, Amit Margalit <AMITM at il.ibm.com> wrote:

Additionally, there is a ton of code to calculate the event size, its 
alignment, and to verify that the names are not longer than the 256 byte 
buffer, and more. 

A couple of thoughts:

(a) there may be a way to share fewer definitions of events across more 
event emit sites. Especially if LTTng supported optional/missing fields :) 
For example, define a single "function.entry" and a single "function.exit" 
instead of a unique definition for each function you have. Disambiguate 
using a parameter.

(b) this is not something that could be done in kernel but in a C++ user 
app it's fairly easy to statically compute everything that depends on 
information known at compile time. I use a custom EDSL implemented via 
boost.proto. As a result, only the stuff that gets used is embedded in 
object code and all event emit calls inline in very fast assembly that's 
optimal for each particular combination of actual argument values.

Cheers,
Vlad_______________________________________________
lttng-dev mailing list
lttng-dev at lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131030/9b6ae060/attachment-0001.html>