[lttng-dev] Performance impact using the "filter" option

[Mathieu Desnoyers]

Other relevant questions are: is the information kept in memory buffers (flight recorder tracing) 
or send to a disk/network output ? When not using the filter, is the ring buffer is "discard" mode, 
or "overwrite" (used for snapshot mode). 

If in discard mode, are there a lot of events discarded ? All those configuration options change 
the picture very significantly. If, for instance, we end up comparing "event discarded" hit most 
of the time with filtering out an event, it's very much possible that the event discard is faster. 
But this is just an artifact of testing in a condition where the data throughput produced by 
the application is larger than what the consumer can cope with (and thus not an expected 
scenario). 

On Intel i7, I had about 50ns runtime cost to filter out an event based on two integer 
comparisons, compared to approx. 250ns to trace the event to a ring buffer in "snapshot 
mode" (overwrite). Then, if we start adding network or disk I/O into the picture by 
configuring the buffers in non-snapshot mode (discard mode), then we have to make 
sure we benchmark in conditions where there are not plenty of discarded events. 

Thanks, 

Mathieu 

----- Original Message -----

> From: "Amit Margalit" <AMITM at il.ibm.com>
> To: "Michel Dagenais" <michel.dagenais at polymtl.ca>
> Cc: "Ilya Mirsky" <ilya.mirsky at gmail.com>, lttng-dev at lists.lttng.org
> Sent: Thursday, March 20, 2014 3:40:15 AM
> Subject: Re: [lttng-dev] Performance impact using the "filter" option

> I agree here - without knowledge of the exact scenario, it's hard to tell.

> Sometimes you need to run the test through many billions of events to see a
> difference.

> Consider this - the filter could be complicated and the event could be tiny
> (say, one integer). In this case, filtering would hurt you even if 99% of
> events are not written to the buffer.

> Amit Margalit
> IBM XIV - Storage Reinvented
> XIV-NAS Development Team
> Tel. 03 -689-7774
> Fax. 03-689-7230

> From: Michel Dagenais <michel.dagenais at polymtl.ca>
> To: Ilya Mirsky <ilya.mirsky at gmail.com>
> Cc: Amit Margalit/Israel/IBM at IBMIL, lttng-dev at lists.lttng.org
> Date: 03/19/2014 10:48 PM
> Subject: Re: [lttng-dev] Performance impact using the "filter" option

> That's what I thought, but benchmarking showed that there's practically no
> difference.
> The filter is a simple ID comparison of the form 'id % 1,000 == 0', so 999
> out of 1K tracepoints are filtered out.
> Could you please point me to some references on this topic?
> What is the running time and trace size with tracing disabled, with tracing
> enabled unconditionally, and with tracing under condition? If tracing takes
> negligible time, filtering will not change much. Note that I have not
> experimented with the current UST filter implementation but with a similar
> facility in GDB and an in-kernel prototype.
> This article is not directly related but discusses many of these issues
> http://benthamscience.com/open/tocsj/articles/V006/11TOCSJ.htm

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

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140320/8ae498d7/attachment.html>