<font size=2 face="sans-serif">This kind of a solution is viable.</font>
<br>
<br><font size=2 face="sans-serif">Here are the concerns we still need
to hammer out for this -</font>
<ul>
<li><font size=2 face="sans-serif">Seeking to an arbitrary time means that
our events (P frames by analogy) need to point to the full shared object
state dump (the I-frame) somehow.</font>
<ul>
<li><font size=2 face="sans-serif">In video compression, the decoder (trace
viewer in our analogy) is assumed to be receiving the stream sequentially
and therefore keeps a copy of N previous frames (and the last I-frame).</font>
<li><font size=2 face="sans-serif">Perhaps in CTF we can circumvent this
problem by storing a field in one of the context headers that will allow
us to quickly seek to the trace position where the full state dump is stored.</font></ul>
<li><font size=2 face="sans-serif">Emitting such a large set of events
could happen at the same time that the system tries to emit high rate of
events, which could cause loss of events.</font>
<ul>
<li><font size=2 face="sans-serif">While loss of events is something we
have to consider "possible", I don't like to add to the chances
of this happening.</font></ul></ul>
<br><font size=2 face="sans-serif">The reason I think putting this in the
metadata is preferable is that this keeps things (IMHO) more in the spirit
of the CTF format - </font>
<br><font size=2 face="sans-serif">=> The trace files are self-contained,
the metadata is in the metadata stream, and in my humble opinion, the symbolic
name of a function is metadata.</font>
<br><font size=2 face="sans-serif">=> The writing of pure application
events / tracepoints is not burdened by writing some overhead (albeit an
important kind of overhead).</font>
<br><font size=2 face="sans-serif">=> The viewers retain the same type
of simplicity that already exists.</font>
<br>
<br><font size=2 face="sans-serif">This is why I really liked Matthew Khouzam's
concept of writing the symbols in the metadata with validity start-time.</font>
<br>
<br><font size=2 face="sans-serif">Amit</font>
<br>
<br><font size=2 color=#000080 face="sans-serif">Amit Margalit</font>
<br><font size=2 color=#808000 face="sans-serif">IBM XIV </font><font size=2 face="sans-serif">-
<i>Storage Reinvented</i></font>
<br><font size=2 face="sans-serif">XIV-NAS Development Team</font>
<br><font size=2 face="sans-serif">Tel. 03</font><font size=2 face="Arial">-689-7774</font>
<br><font size=2 face="Arial">Fax. 03-689-7230</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Woegerer, Paul"
<Paul_Woegerer@mentor.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Amit Margalit/Israel/IBM@IBMIL</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">lttng-dev <lttng-dev@lists.lttng.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Matthew Khouzam
<matthew.khouzam@ericsson.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/11/2013 03:24 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [lttng-dev]
Getting function names with lttng-ust-cyg-profile.so</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>On 09/11/2013 11:12 AM, Amit Margalit wrote:</font>
<br><font size=2 face="sans-serif">I agree with Paul, that no redundant
data gets replicated with his approach, and my only concern is that this
approach really forces a viewer to be sequential.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Maybe "forces" is too strong a word - but a viewer than wants
to let you "roam" the trace freely will have to read the entire
trace to figure out the mapping between address and symbol at each point
in time.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
At this time, we keep 10GB worth of LTTng traces in our system, but future
models will certainly use more. A user asking to go to the end of the trace
will have to wait until the entire trace is read in order to see correct
translations.</font><font size=3> </font>
<br><font size=3><br>
We could provide a solution to this problem with my approach by emitting
an update of the shared object state info every n x K events (configurable).<br>
<br>
Assuming we have a 10GB trace data set, we could emit a full shared object
state dump after every 100K events of regular trace data (with the same
baddr_init events we emit at session_start time). By doing so you don't
need to start reading the entire trace from the beginning. Just start reading
100K events before the events you are interested in, and you can guarantee
to find a "key frame" for shared object state info.<br>
<br>
Note that this is the same concept as used by video compression/streaming:<br>
I‑frame, P‑frame, P‑frame, P‑frame, ..., I‑frame, P‑frame,
P‑frame, P‑frame, ...<br>
See: </font><a href=http://en.wikipedia.org/wiki/Video_compression_picture_types><font size=3 color=blue><u>http://en.wikipedia.org/wiki/Video_compression_picture_types</u></font></a><font size=3><br>
<br>
Best,<br>
Paul<b><br>
</b></font>
<br><font size=2 face="sans-serif"><b><br>
I have a different solution, which I think I have explained here before:
</b></font><a href="http://lists.lttng.org/pipermail/lttng-dev/2013-August/021263.html"><font size=3 color=blue><b><u>http://lists.lttng.org/pipermail/lttng-dev/2013-August/021263.html</u></b></font></a><font size=3><b>
<br>
</b></font><font size=2 face="sans-serif"><b><br>
I vote for adding this to the metadata. It can be in addition to the ust_baddr
events suggeted by Paul.</b></font><font size=3><b> <br>
</b></font><font size=2 face="sans-serif"><b><br>
Amit</b></font><font size=3><b> <br>
</b></font><font size=2 color=#000080 face="sans-serif"><b><br>
Amit Margalit</b></font><font size=3><b> </b></font><font size=2 color=#808000 face="sans-serif"><b><br>
IBM XIV </b></font><font size=2 face="sans-serif"><b>- <i>Storage Reinvented</i></b></font><font size=3><b>
</b></font><font size=2 face="sans-serif"><b><br>
XIV-NAS Development Team</b></font><font size=3><b> </b></font><font size=2 face="sans-serif"><b><br>
Tel. 03</b></font><font size=2 face="Arial"><b>-689-7774</b></font><font size=3><b>
</b></font><font size=2 face="Arial"><b><br>
Fax. 03-689-7230</b></font><font size=3><b> <br>
<br>
<br>
</b></font><font size=1 color=#5f5f5f face="sans-serif"><b><br>
From: </b></font><font size=1 face="sans-serif"><b>"Woegerer,
Paul" </b></font><a href=mailto:Paul_Woegerer@mentor.com><font size=1 color=blue face="sans-serif"><b><u><Paul_Woegerer@mentor.com></u></b></font></a><font size=3><b>
</b></font><font size=1 color=#5f5f5f face="sans-serif"><b><br>
To: </b></font><font size=1 face="sans-serif"><b>Matthew
Khouzam </b></font><a href=mailto:matthew.khouzam@ericsson.com><font size=1 color=blue face="sans-serif"><b><u><matthew.khouzam@ericsson.com></u></b></font></a><font size=3><b>
</b></font><font size=1 color=#5f5f5f face="sans-serif"><b><br>
Cc: </b></font><font size=1 face="sans-serif"><b>lttng-dev
</b></font><a href="mailto:lttng-dev@lists.lttng.org"><font size=1 color=blue face="sans-serif"><b><u><lttng-dev@lists.lttng.org></u></b></font></a><font size=1 face="sans-serif"><b>,
Mathieu Desnoyers </b></font><a href=mailto:mathieu.desnoyers@efficios.com><font size=1 color=blue face="sans-serif"><b><u><mathieu.desnoyers@efficios.com></u></b></font></a><font size=3><b>
</b></font><font size=1 color=#5f5f5f face="sans-serif"><b><br>
Date: </b></font><font size=1 face="sans-serif"><b>09/10/2013
06:47 PM</b></font><font size=3><b> </b></font><font size=1 color=#5f5f5f face="sans-serif"><b><br>
Subject: </b></font><font size=1 face="sans-serif"><b>Re:
[lttng-dev] Getting function names with lttng-ust-cyg-profile.so</b></font><font size=3><b>
</b><br>
</font>
<hr noshade><font size=3><b><br>
<br>
</b></font><tt><font size=2><b><br>
On 09/10/2013 05:37 PM, Matthew Khouzam wrote:<br>
> On 13-09-10 03:00 AM, Woegerer, Paul wrote:<br>
>> Hi Alexandre,<br>
>><br>
>> For trivial examples you can go with 'nm -CS' (or the like), but
when<br>
>> you start to use liblttng-ust-cyg-profile.so in combination with
shared<br>
>> objects you will need to record base address information as well
(to<br>
>> allow you map a virtual memory address at a given point in time
to<br>
>> offset and path of a shared object (or executable)).<br>
>><br>
>> That is one of the reasons why I have submitted:<br>
>> </b></font></tt><a href="http://lists.lttng.org/pipermail/lttng-dev/2013-August/021264.html"><tt><font size=2 color=blue><b><u>http://lists.lttng.org/pipermail/lttng-dev/2013-August/021264.html</u></b></font></tt></a><tt><font size=2><b><br>
> This is a very interesting approach, +1 from me on that.<br>
<br>
Thanks.<br>
<br>
With that approach no redundant data (that is already available as<br>
debuginfo) gets replicated in the actual trace data.<br>
Only the bare minimum of information gets traced to allow you at any<br>
time to map a VM address to a debuginfo address + debuginfo location.<br>
<br>
-- <br>
Paul Woegerer, SW Development Engineer<br>
Sourcery Analyzer <</b></font></tt><a href=http://go.mentor.com/sourceryanalyzer><tt><font size=2 color=blue><b><u>http://go.mentor.com/sourceryanalyzer</u></b></font></tt></a><tt><font size=2><b>><br>
Mentor Graphics, Embedded Software Division<br>
<br>
<br>
_______________________________________________<br>
lttng-dev mailing list</b></font></tt><tt><font size=2 color=blue><b><u><br>
</u></b></font></tt><a href="mailto:lttng-dev@lists.lttng.org"><tt><font size=2 color=blue><b><u>lttng-dev@lists.lttng.org</u></b></font></tt></a><font size=3 color=blue><b><u><br>
</u></b></font><a href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev"><tt><font size=2 color=blue><b><u>http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</u></b></font></tt></a><tt><font size=2><b><br>
</b></font></tt><font size=3><b><br>
</b></font>
<br><font size=3><b><br>
</b></font>
<br><tt><font size=3>-- <br>
Paul Woegerer, SW Development Engineer<br>
Sourcery Analyzer </font></tt><a href=http://go.mentor.com/sourceryanalyzer><tt><font size=3 color=blue><u><http://go.mentor.com/sourceryanalyzer></u></font></tt></a><tt><font size=3><br>
Mentor Graphics, Embedded Software Division</font></tt>
<br>