[ltt-dev] UST double-buffering won't always trigger consumer daemon

Anders Carlsson capricornalpha2 at gmail.com
Mon Oct 31 03:12:18 EDT 2011


Hello!

I working on a UST port, but I cannot _reliably_ get trace data trough to
the consumer daemon. To me it seems the traced application fails to trigger
the consumer daemon when a sub-buffer boundary is crossed.

>From buffers.h:

static __inline__ void ltt_check_deliver(struct ust_channel *chan,
        struct ust_buffer *buf,
        long offset, long commit_count, long idx)
{
    long old_commit_count = commit_count - chan->subbuf_size;

    /* Check if all commits have been done */
    if (unlikely((BUFFER_TRUNC(offset, chan)
            >> chan->n_subbufs_order)
            - (old_commit_count
               & chan->commit_count_mask) == 0)) {
...

This condition becomes true only when commit_count equals a multiple of
chan->subbuf_size, but when I add a printout of the values it appears that
the buffer boundary is often crossed without commit_count ever becoming
equal to the subbuffer size. In those cases, the trace ceases to operate.
This seems to depend on the various tracepoint data sizes, and the order of
commit etc.

I suppose this could be taken care of by aligning the reservations to the
subbuffer boundaries. It seems to me there is already code to handle that
(in ltt_relay_try_reserve_slow()) Am I correct?

Am I missing something (e.g. alignment differences between ARM and x86)?

Should I look somewhere specific?

Thank you for reading this far. Any help is appreciated.

Kind regards
Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20111031/8868ab1e/attachment-0003.htm>


More information about the lttng-dev mailing list