[lttng-dev] [ltt-dev] Flight-recording mode

[Mathieu Desnoyers]

* Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
> On 11/10/2011 09:06 AM, Gerlando Falauto wrote:
>> On 10/28/2011 09:39 AM, Mathieu Desnoyers wrote:
>>> * Gerlando Falauto (gerlando.falauto at keymile.com) wrote:
>> [...]
>>>> How can I make sure that only the latest N seconds of traces will be
>>>> saved? The answer should be flight-recording mode, but how do I really
>>>> do it?
>>>
>>> I discussed this with David this morning, and we'll need to enhance
>>> ltt-sessiond in lttng-tools to ensure it does not send the streams to
>>> the consumer daemon upon trace start for overwrite mode channels, but
>>> just on trace stop. This is lacking currently.
>>>
>>> Thanks for reporting this!
>>
>
> Would the following one-line patch do the trick?
> It kinda-maybe-seems-to-sorta-work for me...
>
> diff --git a/lib/ringbuffer/ring_buffer_vfs.c  
> b/lib/ringbuffer/ring_buffer_vfs.c
> index 8b78305..7676688 100644
> --- a/lib/ringbuffer/ring_buffer_vfs.c
> +++ b/lib/ringbuffer/ring_buffer_vfs.c
> @@ -123,7 +123,7 @@ retry:
>                                 else
>                                         return 0;
>                         }
> -               } else {
> +               } else if (config->mode != RING_BUFFER_OVERWRITE ||  
> finalized) {
>                         if  
> (subbuf_trunc(lib_ring_buffer_get_offset(config, buf),
>                                          chan)
>                           -  
> subbuf_trunc(lib_ring_buffer_get_consumed(config, buf),

Yep, I guess it should work, but I'm not sure that's how we want to do
it upstream: the side-effect is that any trace buffer in overwrite mode
will contain "no data" to be read until it is "destroyed", which sends
the POLLHUP to the consumer, thus letting it read all the data.

This works fine for a one-time snapshot mode, but if you want to take
snapshots repeatedly, a more evolved approach is needed, where the
consumer is aware of the moment when it should read.

Also, the downside of the approach you propose here is that you'll have
to have a consumer sitting around during tracing, sitting on a poll()
doing nothing, but wasting some memory by its mere existance.

So yes, it's a clever trick that should work for one-time snapshots with
flight recorder, but I don't think it fits nicely with the other
features (e.g. ability to take multiple snapshots in a session).

Thanks,

Mathieu

>
>
> Thanks!
> Gerlando
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com