Messages in this thread | | | Date | Thu, 18 Nov 2010 15:00:33 +0900 | From | Masami Hiramatsu <> | Subject | Re: [ANNOUNCE] New utility: 'trace' |
| |
(2010/11/18 0:43), 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? > > Most people I've heard -- both at LinuxCon.JP and LPC -- are asking for > lower overhead tracing (while at the same time demanding more features).
I've also heard a dynamic filtering (or kicking buffer snapshot) request in LinuxCon.JP. I think filtering is not only for filtering-out purpose, but also useful for hooking event to take some action. :)
Thank you,
-- Masami HIRAMATSU 2nd Dept. Linux Technology Center Hitachi, Ltd., Systems Development Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |