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" <[email protected]> > To: "Michel Dagenais" <[email protected]> > Cc: "Ilya Mirsky" <[email protected]>, [email protected] > 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 <[email protected]> > To: Ilya Mirsky <[email protected]> > Cc: Amit Margalit/Israel/IBM@IBMIL, [email protected] > 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 > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
