Messages in this thread |  | | | Date | Fri, 28 Aug 2009 10:03:21 +0800 | | From | Li Zefan <> | | Subject | Re: blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA |
| |
Ingo Molnar wrote: > * Jens Axboe <jens.axboe@oracle.com> wrote: > >> On Wed, Aug 26 2009, Christoph Hellwig wrote: >>> On Wed, Aug 26, 2009 at 10:40:27PM +0200, Ingo Molnar wrote: >>>> We are also converting non-trivial plugins to generic tracepoints. A >>>> recent example are the system call tracepoints, but we also >>>> converted blktrace and kmemtrace to generic tracepoints. >>> On something semi-related: Any reason to keep the blktrace >>> ftrace plugin around? I don't think there's much point in it. >>> It only got added in 2.6.29, and all the blktrace tooling just >>> uses the legacy ioctls. All new uses should just use the >>> TRACE_EVENT output. >> Lets kill it. > > Agreed. > > I think we should keep the relayfs and ioctl compatibility bits > though: blktrace has a mature user-space environment with many > years of installed base. > > We could even move those bits back to block/blktrace_compat.c or so > (after the ftrace plugin bits are removed), to make sure it's nicely > isolated. > > What do you think? >
I'm all for removing the ftrace plugin. There're 2 concerns:
- dev_t info can't be recorded in some blk trace events. I think this will change in the future when we can map a request_queue to a unique device?
- Not all the output of ftrace plugin comes from tracepoints probing, but via blk_add_trace_msg(), which directly writes a string into ring buffer. I think they need to be converted to TRACE_EVENT.
|  |