* blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA [not found] ` <20090826204027.GA21159@elte.hu> @ 2009-08-27 0:30 ` Christoph Hellwig 2009-08-27 5:26 ` Jens Axboe 0 siblings, 1 reply; 6+ messages in thread From: Christoph Hellwig @ 2009-08-27 0:30 UTC (permalink / raw) To: Ingo Molnar; +Cc: rostedt, fweisbec, acme, jens.axboe, linux-kernel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA 2009-08-27 0:30 ` blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA Christoph Hellwig @ 2009-08-27 5:26 ` Jens Axboe 2009-08-27 9:12 ` Ingo Molnar 0 siblings, 1 reply; 6+ messages in thread From: Jens Axboe @ 2009-08-27 5:26 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Ingo Molnar, rostedt, fweisbec, acme, linux-kernel 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. -- Jens Axboe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA 2009-08-27 5:26 ` Jens Axboe @ 2009-08-27 9:12 ` Ingo Molnar 2009-08-27 9:14 ` Jens Axboe 2009-08-28 2:03 ` Li Zefan 0 siblings, 2 replies; 6+ messages in thread From: Ingo Molnar @ 2009-08-27 9:12 UTC (permalink / raw) To: Jens Axboe, Li Zefan Cc: Christoph Hellwig, rostedt, fweisbec, acme, linux-kernel * 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? Ingo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA 2009-08-27 9:12 ` Ingo Molnar @ 2009-08-27 9:14 ` Jens Axboe 2009-08-27 13:55 ` Arnaldo Carvalho de Melo 2009-08-28 2:03 ` Li Zefan 1 sibling, 1 reply; 6+ messages in thread From: Jens Axboe @ 2009-08-27 9:14 UTC (permalink / raw) To: Ingo Molnar Cc: Li Zefan, Christoph Hellwig, rostedt, fweisbec, acme, linux-kernel On Thu, Aug 27 2009, 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? Of course, we have to retain the ioctl/relayfs interface, it's been in use for years. Keeping those out of the other trace/ bits sounds sane. -- Jens Axboe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA 2009-08-27 9:14 ` Jens Axboe @ 2009-08-27 13:55 ` Arnaldo Carvalho de Melo 0 siblings, 0 replies; 6+ messages in thread From: Arnaldo Carvalho de Melo @ 2009-08-27 13:55 UTC (permalink / raw) To: Jens Axboe Cc: Ingo Molnar, Li Zefan, Christoph Hellwig, rostedt, fweisbec, acme, linux-kernel Em Thu, Aug 27, 2009 at 11:14:54AM +0200, Jens Axboe escreveu: > On Thu, Aug 27 2009, 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? > > Of course, we have to retain the ioctl/relayfs interface, it's been in > use for years. Keeping those out of the other trace/ bits sounds sane. Yeah, I wonder tho if we couldn't somehow use the ring buffer infrastructure in such a way as to provide the debugfs visible interface provided by relayfs, IIRC systemtap is doing such a move too. - Arnaldo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA 2009-08-27 9:12 ` Ingo Molnar 2009-08-27 9:14 ` Jens Axboe @ 2009-08-28 2:03 ` Li Zefan 1 sibling, 0 replies; 6+ messages in thread From: Li Zefan @ 2009-08-28 2:03 UTC (permalink / raw) To: Ingo Molnar Cc: Jens Axboe, Christoph Hellwig, rostedt, fweisbec, acme, linux-kernel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-08-28 2:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20090826181502.GC13632@elte.hu>
[not found] ` <20090826190435.GC10816@hmsreliant.think-freely.org>
[not found] ` <20090826190830.GF13632@elte.hu>
[not found] ` <20090826.123631.79533250.davem@davemloft.net>
[not found] ` <20090826194835.GA16508@elte.hu>
[not found] ` <20090826202344.GE10816@hmsreliant.think-freely.org>
[not found] ` <20090826204027.GA21159@elte.hu>
2009-08-27 0:30 ` blktrace ftrace plugin, was Re: Receive side performance issue with multi-10-GigE and NUMA Christoph Hellwig
2009-08-27 5:26 ` Jens Axboe
2009-08-27 9:12 ` Ingo Molnar
2009-08-27 9:14 ` Jens Axboe
2009-08-27 13:55 ` Arnaldo Carvalho de Melo
2009-08-28 2:03 ` Li Zefan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox