* 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