[tracing] ring_buffer question

[tracing] ring_buffer question

[Jon Masters]

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.

Re: [tracing] ring_buffer question

[Jon Masters]

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.

Re: [tracing] ring_buffer question

[David Smith]

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)

Re: [tracing] ring_buffer question

[Steven Rostedt]

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

Re: [tracing] ring_buffer question

[David Smith]

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)

Re: [tracing] ring_buffer question

[Steven Rostedt]

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