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

[Gerlando Falauto]

On 12/15/2011 11:40 PM, Mathieu Desnoyers wrote:
> * 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).

Of course I didn't expect it to be the ultimate solution, but I'm much 
relieved to hear it's usable for my purposes, without any fear of its 
results being untrustworthy.

Needless to say, I would love to hear the announcement of the final 
solution. That'd make a wonderful Xmas present, should you have been 
struggling to figure out what to get me. :-)))

Thanks!
Gerlando