Messages in this thread | | | Subject | Re: [ANNOUNCE] New utility: 'trace' | From | Steven Rostedt <> | Date | Wed, 17 Nov 2010 11:15:21 -0500 |
| |
On Wed, 2010-11-17 at 16:43 +0100, Peter Zijlstra wrote: > On Wed, 2010-11-17 at 10:10 -0500, Steven Rostedt wrote: > > > > Right, the problem with filtering is what do we want to filter, and what > > about copying? > > > > Currently, we copy the data into the buffer and then filter on that > > data. We could also easily filter on the parameters of the tracepoint, > > but sometimes those parameters do not match the final output (as the > > case with sched_switch). Do we copy the data into a separate "per cpu" > > temp buffer, and figure out the filter then? And if the filter is fine, > > then copy into the buffer. This obviously is slow, due to the multiple > > copies. We could do this only if the filtering is enabled. > > Right, so what is the primary purpose of this filtering stuff? As it > stands it makes stuff terribly slow, so you add overhead but the win > (presumably) is less data output, is that a sane trade-off?
I've actually used filtering too. Not for speed up, but because I was recording a lot of data and the reader could not keep up. By filtering, I was able to get all the relevant information without needing to make the kernel buffer a Gig.
-- Steve
| |