[ltt-dev] ltt channel thread safe?

[Pierre-Marc Fournier]

On 08/04/2010 02:12 AM, chris meyers wrote:
> To give a bit of context to the problem.  I am using user space ltt to
> help profile code.  I have created two events, time_begin and time_end.
>   The goal is to allow for logging the runtime of specific code blocks
> via start() stop() insertions.
>
> I am having some issues with traces not coming out "correct" on the
> other "end".  Let me further explain what I mean by correct and end.
>
> correct
> trace_mark(ust, time_begin, "thread %d func %s depth %d extra %s", 0,
> __FUNCTION__, 1, __FUNCTION__)
> trace_mark(ust, time_end, "thread %d func %s depth %d extra %s", 0,
> __FUNCTION__, 1, __FUNCTION__)
>
> end
> ust.time_begin: 30208.932264102
> (/home/meyers/.usttraces/lappy-20100804020140730811027/28367_5501430910891543571/ust_0),
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { thread = 1, func =
> "memloc_request_response_decider", depth = 1, extra =
> "memloc_request_response_decider" }
> ust.time_end: 30208.932267455
> (/home/meyers/.usttraces/lappy-20100804020140730811027/28367_5501430910891543571/ust_0),
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { thread = 1, func =
> "memloc_request_response_decider", depth = 1, extra =
> "memloc_request_response_decider" }
>
> Later on the output looks like this:
> ust.time_begin: 30198.142843837
> (/home/meyers/.usttraces/lappy-20100804020140730811027/28367_5501430910891543571/ust_0),
> 0, 0, , , 0, 0x0, MODE_UNKNOWN { thread = 1, func = "ne_worker_thread",
> depth = 560296821, extra = "" }
>
> Notice that in the trace_mark() code above I hard coded depth to be 0
> and _str is always __FUNCTION__.
>
> Possible reasons:
> * Buffer is being overrun.  I changed the buffer size using the -N and
> -S options in usttrace to something > 2 MB (plenty large).
> * Channels are not thread-safe?  I have 3 threads of execution in this
> example.  All using the ust channel.

Channels are supposed to be thread-safe.

If there is an overrun, it will be printed in the console output from 
lttv. Overruns are always possible if the rate at which the application 
produces events is higher than the rate at which they can be flushed to 
the disk. The solution may be to increase buffer size to counter 
temporary event rate peaks. However if the sustained rate is too high, 
an overrun will still eventually happen. One way to avoid this would be 
to add a synchronous mode where the application may block on a marker to 
prevent overruns.

> * My code is crappy and I am overwriting the lust library buffer?
>
>
> Also, I am having trouble using any channel other than ust.  Is ust the
> only channel available in user space?

 From the ust manual:

"Note: Although this example uses mychannel as the channel, the only 
channel name currently supported with early tracing is ust. The usttrace 
tool always uses the early tracing mode. When using manual mode without 
early tracing, any channel name may be used."

pmf