[PATCH 0/4] tracing: event filtering v2

[PATCH 0/4] tracing: event filtering v2

[Tom Zanussi]

Hi,

This is version 2 of my patchset adding filtering to the event-tracing
infrastructure.

Changes from the previous version:

- added common_ prefix to the 5 common event fields
- ring_buffer_event_discard() fixes from Steven Rostedt
- changed 'and' and 'or' for compound filters to '&&' and '||'
- fixed a bug in the matching logic 

Everything seems to work ok for me, but I haven't yet gotten around to
changing the awkward UI.  I plan to fix that as soon as I can i.e. allow
complete compound expressions to be specified all at once, add <, >, <=,
>= and parens, etc.  Until then, it should hopefully be usable for basic
filtering. 

Thanks,

Tom

Re: [PATCH 0/4] tracing: event filtering v2

[Ingo Molnar]

* Tom Zanussi <tzanussi@gmail.com> wrote:

> Hi,
> 
> This is version 2 of my patchset adding filtering to the 
> event-tracing infrastructure.
> 
> Changes from the previous version:
> 
> - added common_ prefix to the 5 common event fields
> - ring_buffer_event_discard() fixes from Steven Rostedt
> - changed 'and' and 'or' for compound filters to '&&' and '||'
> - fixed a bug in the matching logic 
> 
> Everything seems to work ok for me, but I haven't yet gotten 
> around to changing the awkward UI.  I plan to fix that as soon as 
> I can i.e. allow complete compound expressions to be specified all 
> at once, add <, >, <=, >= and parens, etc.  Until then, it should 
> hopefully be usable for basic filtering.

Thanks Tom - Frederic and me had a good look and i picked them up 
into tip:tracing/filters for now and lets see how they hold up in 
testing. There was one boundary-condition bug Frederic noticed, i 
fixed that.

The subsystem level filters are a nice touch. We still have to 
complete and organize events into a comprehensive, Linux-wide set of 
tracepoints, so there will be some churn in this area.

	Ingo

Re: [PATCH 0/4] tracing: event filtering v2

[Tom Zanussi]

On Sun, 2009-03-22 at 20:56 +0100, Ingo Molnar wrote:
> * Tom Zanussi <tzanussi@gmail.com> wrote:
> 
> > Hi,
> > 
> > This is version 2 of my patchset adding filtering to the 
> > event-tracing infrastructure.
> > 
> > Changes from the previous version:
> > 
> > - added common_ prefix to the 5 common event fields
> > - ring_buffer_event_discard() fixes from Steven Rostedt
> > - changed 'and' and 'or' for compound filters to '&&' and '||'
> > - fixed a bug in the matching logic 
> > 
> > Everything seems to work ok for me, but I haven't yet gotten 
> > around to changing the awkward UI.  I plan to fix that as soon as 
> > I can i.e. allow complete compound expressions to be specified all 
> > at once, add <, >, <=, >= and parens, etc.  Until then, it should 
> > hopefully be usable for basic filtering.
> 
> Thanks Tom - Frederic and me had a good look and i picked them up 
> into tip:tracing/filters for now and lets see how they hold up in 
> testing. There was one boundary-condition bug Frederic noticed, i 
> fixed that.
> 
> The subsystem level filters are a nice touch. We still have to 
> complete and organize events into a comprehensive, Linux-wide set of 
> tracepoints, so there will be some churn in this area.

Thanks!  I just posted 3 patches fixing some problems I saw while
reviewing the subsystem code as well.

Tom

> 
> 	Ingo

Re: [PATCH 0/4] tracing: event filtering v2

[Frederic Weisbecker]

On Sun, Mar 22, 2009 at 03:30:26AM -0500, Tom Zanussi wrote:
> Hi,
> 
> This is version 2 of my patchset adding filtering to the event-tracing
> infrastructure.
> 
> Changes from the previous version:
> 
> - added common_ prefix to the 5 common event fields
> - ring_buffer_event_discard() fixes from Steven Rostedt
> - changed 'and' and 'or' for compound filters to '&&' and '||'
> - fixed a bug in the matching logic 
> 
> Everything seems to work ok for me, but I haven't yet gotten around to
> changing the awkward UI.  I plan to fix that as soon as I can i.e. allow
> complete compound expressions to be specified all at once, add <, >, <=,
> >= and parens, etc.  Until then, it should hopefully be usable for basic
> filtering. 
> 
> Thanks,
> 
> Tom
> 


Very nice work!

My events/1 task is pid 4, and swapper (idle) is 0,

cd /debug/tracing/events/sched/sched_switch
echo prev_pid == 4 > filter
echo "&& next_pid == 0" > filter
echo 1 > enable


cat /debug/tracing/trace

# tracer: nop
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
           <...>-4     [000]  1136.993069: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1136.993081: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1137.218492: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1137.283787: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1137.458733: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1137.560932: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1137.560941: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1137.741107: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1138.159083: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1138.338673: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1138.338681: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1138.517769: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1138.517833: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
           <...>-4     [000]  1138.517845: sched_switch: task events/0:4 [115] ==> swapper:0 [140]
[...]


:-)