[ltt-dev] lttng development plan

[zhaolei@cn.fujitsu.com (Zhaolei)]

* Mathieu Desnoyers Wrote:
> 
>   - Create an in-kernel event filtering module which connects on
>     LTTng.
> 
> Well, I think this last item would be a generalization of the filtering
> module I created for ext4 and jbd2 recently. The one I did provided
> basic filtering for inode and device number.
Hello, Matuieu

I readed filter code of ext4 and jbd2 module,
and I have some questions of generalization filter implementation.

> 
> The idea would be to extend this and to connect it as a filter callback
> with 
> ltt_module_register(LTT_FUNCTION_RUN_FILTER, filter_callback,
>                     THIS_MODULE);
Now ltt_module_register can only register one filter_callback.
But I think when we make one filter for all types of tracepoint, it is hard to
maintenance.

Maybe it is better to make each filter for each type of event, for ex:
ltt-ext4-filter for ext4, ltt-jbd2-filter for jbd2, ...

We can select to add filter code into ltt/probes/XXX_trace.c, and call
ltt_module_register on modile_init, or write filter code in a module alone.
Each way is ok, but integrate filter code into ltt/probes/XXX_trace.c seems
more readable.

Another thing needs consider is call which filter on a event.
1: Call every filter for one event.
   If one filter say "no", this event is ignore.
   It is simple to write, and each filter can do every thing(flexible).
   But this way is inefficient because it needs more cpu cycles.
2: Call only filter for current event type.
   Filter register a event type on ltt_module_register, and only used to
   process that type.
I think 2 is better because it uses less CPU.

> 
> This module would be called by ltt_vtrace and _ltt_specialized_trace
> with this test :
> 
>                 if (unlikely(!ltt_run_filter(trace, eID)))
>                         continue;
> 
> for each active trace.
I think call filter in tracepoint's callback as probe_jbd2_checkpoint is
more efficient than this way.
Consider that a event which is filtered(don't send to relay), more
unnecessary process is done before ltt_vtrace if we call filter in ltt_vtrace.

So, in generalization filter:
1: call filter in ltt_vtrace(_ltt_specialized_trace)
2: call filter in probe_XXX_checkpoint()
I think 2 is better.

Which is your opinion about this?

B.R.
Zhaolei

> 
> This filter would receive the trace information and the event ID.
> We may have to add or change some parameters to this to support
> filtering by fields. For the filter called from ltt_vtrace, passing :
> 
> const struct marker *mdata
> and
> const char *fmt, va_list *args
> 
> Should be more than enough to filter generically by
> - channel name
> - event name
> - field name -> typed field data.
> 
> Filtering should be pre-computed as much as possible and be O(1) when
> executed. Creating callbacks for each expected data type to filter will
> probably be requried. A technique similar to what we have done in lttv
> filter.c should be considered.
> 
> For specialized probes, it might be more difficult to do this
> generically, because _ltt_specialized_trace has no knowledge of the
> event fields. I guess we would have to create "specialized" filtering
> callbacks for those custom trace points. It's their nature anyway.
> 
> Please ask if anything is unclear. Comments/ideas are welcome.
> 
> Mathieu
>