[lttng-dev] Getting function names with lttng-ust-cyg-profile.so

Wed Sep 11 10:30:04 EDT 2013

This kind of a solution is viable.

Here are the concerns we still need to hammer out for this -
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.
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).
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.
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.
While loss of events is something we have to consider "possible", I don't 
like to add to the chances of this happening.

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 - 
=> 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.
=> The writing of pure application events / tracepoints is not burdened by 
writing some overhead (albeit an important kind of overhead).
=> The viewers retain the same type of simplicity that already exists.

This is why I really liked Matthew Khouzam's concept of writing the 
symbols in the metadata with validity start-time.

Amit

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

From:   "Woegerer, Paul" <Paul_Woegerer at mentor.com>
To:     Amit Margalit/Israel/IBM at IBMIL
Cc:     lttng-dev <lttng-dev at lists.lttng.org>, Mathieu Desnoyers 
<mathieu.desnoyers at efficios.com>, Matthew Khouzam 
<matthew.khouzam at ericsson.com>
Date:   09/11/2013 03:24 PM
Subject:        Re: [lttng-dev] Getting function names with 
lttng-ust-cyg-profile.so

On 09/11/2013 11:12 AM, Amit Margalit wrote:
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. 

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. 

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. 

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).

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.

Note that this is the same concept as used by video compression/streaming:
I?frame, P?frame, P?frame, P?frame, ..., I?frame, P?frame, P?frame, 
P?frame, ...
See: http://en.wikipedia.org/wiki/Video_compression_picture_types

Best,
Paul

I have a different solution, which I think I have explained here before: 
http://lists.lttng.org/pipermail/lttng-dev/2013-August/021263.html 

I vote for adding this to the metadata. It can be in addition to the 
ust_baddr events suggeted by Paul. 

Amit 

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

From:        "Woegerer, Paul" <Paul_Woegerer at mentor.com> 
To:        Matthew Khouzam <matthew.khouzam at ericsson.com> 
Cc:        lttng-dev <lttng-dev at lists.lttng.org>, Mathieu Desnoyers 
<mathieu.desnoyers at efficios.com> 
Date:        09/10/2013 06:47 PM 
Subject:        Re: [lttng-dev] Getting function names with 
lttng-ust-cyg-profile.so 

On 09/10/2013 05:37 PM, Matthew Khouzam wrote:
> On 13-09-10 03:00 AM, Woegerer, Paul wrote:
>> Hi Alexandre,
>>
>> For trivial examples you can go with 'nm -CS' (or the like), but when
>> you start to use liblttng-ust-cyg-profile.so in combination with shared
>> objects you will need to record base address information as well (to
>> allow you map a virtual memory address at a given point in time to
>> offset and path of a shared object (or executable)).
>>
>> That is one of the reasons why I have submitted:
>> http://lists.lttng.org/pipermail/lttng-dev/2013-August/021264.html
> This is a very interesting approach, +1 from me on that.

Thanks.

With that approach no redundant data (that is already available as
debuginfo) gets replicated in the actual trace data.
Only the bare minimum of information gets traced to allow you at any
time to map a VM address to a debuginfo address + debuginfo location.

-- 
Paul Woegerer, SW Development Engineer
Sourcery Analyzer <http://go.mentor.com/sourceryanalyzer>
Mentor Graphics, Embedded Software Division

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

-- 
Paul Woegerer, SW Development Engineer
Sourcery Analyzer <http://go.mentor.com/sourceryanalyzer>
Mentor Graphics, Embedded Software Division
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130911/223be4b1/attachment-0001.html>