* [tracing] ring_buffer question
@ 2009-05-17 21:08 Jon Masters
2009-05-18 0:39 ` Jon Masters
0 siblings, 1 reply; 6+ messages in thread
From: Jon Masters @ 2009-05-17 21:08 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-kernel
Steven,
Is there any reason you can think of why we don't just generalize
kernel/trace/ring_buffer into kernel/ring_buffer, remove the static
per_cpu buffer allocation and have this available for non-tracing?
As it is, trace buffers only store generic data and the design (swap on
read) is very nicely done for many other ring buffer uses.
Jon.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tracing] ring_buffer question
2009-05-17 21:08 [tracing] ring_buffer question Jon Masters
@ 2009-05-18 0:39 ` Jon Masters
2009-05-18 15:58 ` David Smith
0 siblings, 1 reply; 6+ messages in thread
From: Jon Masters @ 2009-05-18 0:39 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-kernel
On Sun, 2009-05-17 at 17:08 -0400, Jon Masters wrote:
> Is there any reason you can think of why we don't just generalize
> kernel/trace/ring_buffer into kernel/ring_buffer, remove the static
> per_cpu buffer allocation and have this available for non-tracing?
Ignore the latter point - I realize that I can use ring_buffer_alloc,
etc. quite happily. I am doing that now in my smi_detector rewrite. But
I still think the RB is a little too tracing specific - so, perhaps we
can move it out of kernel/trace. I'll write up something once I've
figured out this stuff to go along with the excellent trace docs since
the generic ring buffer implementation is really quite sexy stuff.
[thinking out loud] Does the global disable stuff also disable other
non-tracing ring buffers?
Jon.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tracing] ring_buffer question
2009-05-18 0:39 ` Jon Masters
@ 2009-05-18 15:58 ` David Smith
2009-05-18 16:23 ` Steven Rostedt
0 siblings, 1 reply; 6+ messages in thread
From: David Smith @ 2009-05-18 15:58 UTC (permalink / raw)
To: Jon Masters; +Cc: Steven Rostedt, linux-kernel
Jon Masters wrote:
> [thinking out loud] Does the global disable stuff also disable other
> non-tracing ring buffers?
I believe it does. If I'm correct, I think it would be a good idea to
make that an ftrace-disable feature, not a general ring buffer disable
feature.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tracing] ring_buffer question
2009-05-18 15:58 ` David Smith
@ 2009-05-18 16:23 ` Steven Rostedt
2009-05-18 16:52 ` David Smith
0 siblings, 1 reply; 6+ messages in thread
From: Steven Rostedt @ 2009-05-18 16:23 UTC (permalink / raw)
To: David Smith; +Cc: Jon Masters, linux-kernel
On Mon, 18 May 2009, David Smith wrote:
> Jon Masters wrote:
> > [thinking out loud] Does the global disable stuff also disable other
> > non-tracing ring buffers?
>
> I believe it does. If I'm correct, I think it would be a good idea to
> make that an ftrace-disable feature, not a general ring buffer disable
> feature.
We can do that when we get more users of the ring buffer and we find it
makes sense.
-- Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tracing] ring_buffer question
2009-05-18 16:23 ` Steven Rostedt
@ 2009-05-18 16:52 ` David Smith
2009-05-18 17:03 ` Steven Rostedt
0 siblings, 1 reply; 6+ messages in thread
From: David Smith @ 2009-05-18 16:52 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Jon Masters, linux-kernel
Steven Rostedt wrote:
> On Mon, 18 May 2009, David Smith wrote:
>
>> Jon Masters wrote:
>>> [thinking out loud] Does the global disable stuff also disable other
>>> non-tracing ring buffers?
>> I believe it does. If I'm correct, I think it would be a good idea to
>> make that an ftrace-disable feature, not a general ring buffer disable
>> feature.
>
> We can do that when we get more users of the ring buffer and we find it
> makes sense.
It appears that oprofile is already using the ring buffer. With Jon's
stuff as a 2nd non-ftrace-user, doesn't it make sense now?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [tracing] ring_buffer question
2009-05-18 16:52 ` David Smith
@ 2009-05-18 17:03 ` Steven Rostedt
0 siblings, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2009-05-18 17:03 UTC (permalink / raw)
To: David Smith; +Cc: Jon Masters, linux-kernel
On Mon, 18 May 2009, David Smith wrote:
> Steven Rostedt wrote:
> > On Mon, 18 May 2009, David Smith wrote:
> >
> >> Jon Masters wrote:
> >>> [thinking out loud] Does the global disable stuff also disable other
> >>> non-tracing ring buffers?
> >> I believe it does. If I'm correct, I think it would be a good idea to
> >> make that an ftrace-disable feature, not a general ring buffer disable
> >> feature.
> >
> > We can do that when we get more users of the ring buffer and we find it
> > makes sense.
>
> It appears that oprofile is already using the ring buffer. With Jon's
> stuff as a 2nd non-ftrace-user, doesn't it make sense now?
I guess it might also be something that we want to consider too. That is,
the "tracing_off" is a nice feature for all users of the ring buffer. Once
can stop and start the oprofiler buffer via the user interface
"tracing_on" as well. Is this something that would also be useful? If we
make it "ftrace only" then oprofile loses this feature.
Now we could make a file for every registered user of the ring buffer.
Well, not every registered user, but have the user register their own
"tracing_on" file.
-- Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-05-18 17:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-17 21:08 [tracing] ring_buffer question Jon Masters
2009-05-18 0:39 ` Jon Masters
2009-05-18 15:58 ` David Smith
2009-05-18 16:23 ` Steven Rostedt
2009-05-18 16:52 ` David Smith
2009-05-18 17:03 ` Steven Rostedt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.