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

[Mathieu Desnoyers]

* 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.

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.

Thoughts ?

Thanks,

Mathieu

>
> Thanks,
> Paul
>

> diff --git a/include/ust/tracectl.h b/include/ust/tracectl.h
> index c0ee7b1..63e0204 100644
> --- a/include/ust/tracectl.h
> +++ b/include/ust/tracectl.h
> @@ -23,6 +23,7 @@ typedef struct ust_fork_info {
>  } ust_fork_info_t;
>  
>  extern void ust_potential_exec(void);
> +extern void wait_for_buffer_consumption();
>  
>  extern void ust_before_fork(ust_fork_info_t *fork_info);
>  extern void ust_after_fork_parent(ust_fork_info_t *fork_info);
> diff --git a/libust/tracectl.c b/libust/tracectl.c
> index 33c7280..b2063e1 100644
> --- a/libust/tracectl.c
> +++ b/libust/tracectl.c
> @@ -1548,6 +1548,16 @@ static void __attribute__((destructor)) keepalive()
>  		return;
>  	}
>  
> +	wait_for_buffer_consumption();
> +
> +	destroy_traces();
> +
> +	/* Ask the listener to stop and clean up. */
> +	stop_listener();
> +}
> +
> +void wait_for_buffer_consumption()
> +{
>  	if (trace_recording() && CMM_LOAD_SHARED(buffers_to_export)) {
>  		int total = 0;
>  		DBG("Keeping process alive for consumer daemon...");
> @@ -1563,11 +1573,6 @@ static void __attribute__((destructor)) keepalive()
>  		}
>  		DBG("Finally dying...");
>  	}
> -
> -	destroy_traces();
> -
> -	/* Ask the listener to stop and clean up. */
> -	stop_listener();
>  }
>  
>  void ust_potential_exec(void)
> 
> 

> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


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