[lttng-dev] [PATCH] tracepoint event exclusion

[lttng-dev] [PATCH] tracepoint event exclusion

[Woegerer, Paul]

Hi,

In order to support situations where a user wants generally all 
tracepoints enabled but specific tracepoints to be suppressed during a 
trace session, I created a small patch that allows us to do the following:

...
lttng enable-event -u -c met_tools -a
lttng enable-event -u -c met_tools --tracepoint '!met_func:*'
lttng enable-event -u -c met_tools --tracepoint '!met_call:*'
...

This has the effect that all tracepoints get recorded except for 
tracepoints that match met_func:* or met_call:*.

If you think this feature is useful for others we would be happy to see 
this patch merged into trunk.

Thanks,
Paul

-- 
Paul Woegerer | SW Development Engineer
Mentor Embedded(tm) | Prinz Eugen Stra?e 72/2/4, Vienna, 1040 Austria
P 43.1.535991320
Nucleus? | Linux? | Android(tm) | Services | UI | Multi-OS

Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: event_exclusion.patch
Type: text/x-patch
Size: 2157 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20120627/3a8a1c68/attachment.bin>

[lttng-dev] [PATCH] tracepoint event exclusion

[Mathieu Desnoyers]

* Woegerer, Paul (Paul_Woegerer at mentor.com) wrote:
> Hi,
>
> In order to support situations where a user wants generally all  
> tracepoints enabled but specific tracepoints to be suppressed during a  
> trace session, I created a small patch that allows us to do the 
> following:
>
> ...
> lttng enable-event -u -c met_tools -a
> lttng enable-event -u -c met_tools --tracepoint '!met_func:*'
> lttng enable-event -u -c met_tools --tracepoint '!met_call:*'

hrm, although possibly interesting, I don't think this semantic follows
the lttng UI event enabling semantic. There are a few use-cases to
cover:

1) enable tracepoints, start tracing, run app.

2) enable some tracepoints, start tracing, run app, enable more
   tracepoints while app is running.

3) start tracing, run app, enable all tracepoints while app is running.

AFAIU, your patch and proposed semantic covers use-case #1, but breaks
the other 2. Basically, we have to apply a logical "or" between each
enable-event command (rather than an "and" as your proposed semantic
suggests), because they can be applied independently.

We could however try to come up with an event attribute that gets
applied on a specific event, e.g.:

lttng enable-event -u -a --exclude 'met_func:*' --exclude 'met_call:*'

thoughts ?

Thanks,

Mathieu

> ...
>
> This has the effect that all tracepoints get recorded except for  
> tracepoints that match met_func:* or met_call:*.
>
> If you think this feature is useful for others we would be happy to see  
> this patch merged into trunk.
>
> Thanks,
> Paul
>
> -- 
> Paul Woegerer | SW Development Engineer
> Mentor Embedded(tm) | Prinz Eugen Stra?e 72/2/4, Vienna, 1040 Austria
> P 43.1.535991320
> Nucleus? | Linux? | Android(tm) | Services | UI | Multi-OS
>
> Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
> Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
>

> From 74602f6f4ea4b1d7faa01f76542f62b496b94091 Mon Sep 17 00:00:00 2001
> From: Paul Woegerer <paul_woegerer@mentor.com>
> Date: Wed, 27 Jun 2012 15:21:30 +0200
> Subject: [PATCH] Added excluding/filtering of events with !NAME
> 
> ---
>  liblttng-ust/ltt-events.c |   33 +++++++++++++++++++++++++++++++--
>  1 file changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/liblttng-ust/ltt-events.c b/liblttng-ust/ltt-events.c
> index 0fdfd2f..b663312 100644
> --- a/liblttng-ust/ltt-events.c
> +++ b/liblttng-ust/ltt-events.c
> @@ -150,11 +150,32 @@ struct wildcard_entry *match_wildcard(const struct lttng_event_desc *desc)
>  	struct wildcard_entry *e;
>  
>  	cds_list_for_each_entry(e, &wildcard_list, list) {
> +	    size_t len = strlen(e->name);
> +	    if (len < 1 || e->name[0] != '!')
> +		continue;
> +
> +	    DBG("Filter %s against wildcard_entry %s\n", desc->name, e->name);
> +
> +	    /* Compare exclusion wildcards excluding initial '!' and final '*' */
> +	    if (!strncmp(desc->name, e->name + 1, len - 2))
> +	    {
> +		DBG("Exclude %s due to exclusion wildcard_entry %s\n", desc->name, e->name);
> +		return NULL; /* exclusion wildcard matched */
> +	    }
> +	}
> +
> +	cds_list_for_each_entry(e, &wildcard_list, list) {
> +	    size_t len = strlen(e->name);
> +	    if (len > 0 && e->name[0] == '!')
> +		continue;
> +
> +	    DBG("Match %s against wildcard_entry %s\n", desc->name, e->name);
> +
>  		/* If only contain '*' */
> -		if (strlen(e->name) == 1)
> +		if (len == 1)
>  			goto possible_match;
>  		/* Compare excluding final '*' */
> -		if (!strncmp(desc->name, e->name, strlen(e->name) - 1))
> +		if (!strncmp(desc->name, e->name, len - 1))
>  			goto possible_match;
>  		continue;	/* goto next, no match */
>  	possible_match:
> @@ -507,6 +528,13 @@ int ltt_event_create(struct ltt_channel *chan,
>  	struct ltt_event *event;
>  	int ret = 0;
>  
> +	if (strlen(event_param->name) > 0 && event_param->name[0] == '!')
> +	{
> +	    struct session_wildcard *sw = NULL;
> +	    ltt_wildcard_create(chan, event_param, &sw );
> +	    goto filter;
> +	}
> +
>  	if (chan->used_event_id == -1U) {
>  		ret = -ENOMEM;
>  		goto full;
> @@ -607,6 +635,7 @@ cache_error:
>  no_loglevel_match:
>  exist:
>  full:
> +filter:
>  	return ret;
>  }
>  
> -- 
> 1.7.10.4
> 

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev


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

[lttng-dev] [PATCH] tracepoint event exclusion

[Woegerer, Paul]

On 06/27/2012 08:33 PM, Mathieu Desnoyers wrote:
>
> hrm, although possibly interesting, I don't think this semantic follows
> the lttng UI event enabling semantic. There are a few use-cases to
> cover:
>
> 1) enable tracepoints, start tracing, run app.
>
> 2) enable some tracepoints, start tracing, run app, enable more
>     tracepoints while app is running.
>
> 3) start tracing, run app, enable all tracepoints while app is running.
>
> AFAIU, your patch and proposed semantic covers use-case #1, but breaks
> the other 2. Basically, we have to apply a logical "or" between each
> enable-event command (rather than an "and" as your proposed semantic
> suggests), because they can be applied independently.

You are right, I only had use-case #1 in mind when I wrote this patch. I 
intentionally kept my modifications small not to break any of the the 
existing functionality if "!" is not used.

Let me provide a more elaborate description of what this patch is doing:

Original behavior:

match_wildcard():
    Check if a wildcard_entry matches the given lttng_event_desc name. 
If a mach is found and the loglevel also matches return the 
wildcard_entry. Otherwise return 0.

ltt_event_create():
    If an event with the given name does not already exist create one, 
pass a pointer to it (via _event) and return 0. If an event with the 
given name already exists return -EEXIST.

Behavior after patch:

match_wildcard():
    First check if there is a wildcard_entry that starts with "!" that 
matches the given lttng_event_desc name. If a filter matches return 0 
(no match). If not proceed as before.

ltt_event_create():
    If an event should be created that starts with "!" do not create it 
but instead add a new wildcard_entry (if not already existing in the 
wildcard_list). Otherwise as before.

Note that the change of ltt_event_create() was necessary to make sure 
that also things like:

lttng enable-event -u -c met_tools --tracepoint '!met_func:enter'

work (i.e. filters that do not have a '*' at the end).

>
> We could however try to come up with an event attribute that gets
> applied on a specific event, e.g.:
>
> lttng enable-event -u -a --exclude 'met_func:*' --exclude 'met_call:*'

I would prefer your "--exclude" over my solution but I doubt that I 
could implement it properly. Are you planning to add "--exclude" 
yourself or could you provide me with detailed instructions how to 
implement it (which functions and structures need to be adapted).

--
Thanks,
Paul

-- 
Paul Woegerer | SW Development Engineer
Mentor Embedded(tm) | Prinz Eugen Stra?e 72/2/4, Vienna, 1040 Austria
P 43.1.535991320
Nucleus? | Linux? | Android(tm) | Services | UI | Multi-OS

Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.