[ltt-dev] [UST PATCH] Request: Make wait_for_buffer_consumption visible

[Mathieu Desnoyers]

* Paul Wögerer (paul_woegerer at mentor.com) wrote:
> Hi Mathieu,
>
> thanks for your reply, see comments below.
>
> On 03/17/2011 02:07 PM, Mathieu Desnoyers wrote:
>> * Paul Wögerer (paul_woegerer at mentor.com) wrote:
>>> Hi,
>>>
>>> I'm trying to use LTTng UST as a backend for function call tracing. The
>>> following pseudocode shows what we basically to:
>>>
>>> ustcmd_set_marker_state( "call_trace", call, enter, 1, pid );
>>> ustcmd_set_marker_state( "call_trace", call, inside, 1, pid );
>>> ustcmd_set_marker_state( "call_trace", call, exit, 1, pid );
>>>
>>> ustcmd_create_trace( "call_trace", pid );
>>> ustcmd_start_trace( "call_trace", pid );
>>>
>>> ...
>>> ... Lots of auto-generated code that makes use of call.enter/inside/exit
>>> markers
>>> ...
>>>
>>> ustcmd_stop_trace( "call_trace", pid );
>>> ustcmd_destroy_trace( "call_trace", pid );
>>>
>>> This works very well in general but whenever an executable runs only for
>>> a very short amount of time I run into troubles with stopping/destroying
>>> my "call_trace" properly.
>>>
>>> This is caused by the fact that stop/destroy_trace runs before buffer
>>> consumption completed on the ust-consumerd side. This is easy to prevent
>>> by some code that implements waiting for buffer consumption. Fortunately
>>> this is already available in tracectl.c keepalive().
>>>
>>> The following patch puts the "waiting for buffer consumption" code into
>>> its own function and makes it visible externally via ust/ustctl.h. Using
>>> function wait_for_buffer_consumption() before stop/destroy_trace solves
>>> the problem for me.
>>>
>>> Please apply the patch from the attachment to the ust trunk to make
>>> wait_for_buffer_consumption()available for everyone.
>> This brings up two interesting questions:
>>
>> a) Do we want to expose the ustcmd_* API to applications at this point
>>     in the development, given the changes that are coming ? The expected
>>     way for an application to use tracing would be to interact with the
>>     external app/lib responsible for tracing rather than controlling this
>>     internally.
>
> While I think the non-intrusive approach that is currently under  
> development is a good thing in terms of usability I also see the  
> advantages of having full control where exactly in the sources I want to  
> start and stop tracing. This feature of the current version of libust  
> should not be abounded. It gives a lot of flexibility that would be  
> hardly missed.
>
> It should be possible to have an executable running that is under  
> external trace control while at the same time allowing the executable to  
> create its own specialized traces based on some conditions that only the  
> executable itself knows.

Sure, this use-case will be taken care of, the question is "how",

>
>> b) Do we want to *ever* expose the ustcmd_* API ? I'm not so sure,
>>     because it drastically changes the way we think about libust.
>>     In the upcoming future, my vision is that libust's only API used by
>>     the application is trace_event/markers. Everything else should be
>>     internal to libust, only presented to the ltt-sessiond through
>>     the communication socket. I'm concerned about the fact that
>>     supporting more than that will send us deep into both API _and_
>>     locking hells.
>
> Would that interface allow me to _dynamically_ declare and use markers  
> inside my code as I can do now with ustcmd_set_marker_state ?
> For example:
>
> if(do_call_trace)
> {
>   ustcmd_set_marker_state( "my_trace", call, enter, 1, pid );
>   ustcmd_set_marker_state( "my_trace", call, inside, 1, pid );
>   ustcmd_set_marker_state( "my_trace", call, exit, 1, pid );
> }
>
> if(do_function)
> {
>   ustcmd_set_marker_state( "my_trace", function, prolog, 1, pid );
>   ustcmd_set_marker_state( "my_trace", function, epilog, 1, pid );
> }
>
> ustcmd_create_and_start_trace( "my_trace", pid );

Yes, the main difference when passing through the ltt-sessiond daemon is
that your application would be two things:

a) a trace data producer (hence it links with libust).
b) a trace controller (hence it links with the new liblttngctl)

So the application can set the marker states, start/stop tracing, spawn
a consumer daemon, etc, but this is not done directly with a libust API:
it's done through the ltt-sessiond throught the liblttngctl API, as if
it was a normal "trace control" application.

Does that make sense ?

Thanks,

Mathieu

>
> --
> Thanks,
> PaulW
>

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