lkml.org 
[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper)
On Sat, 20 Dec 2008, Pekka Paalanen wrote:

> >
> > To implement this at the ftrace level should be a trivial change. I'm just
> > saying that doing this at the "ring buffer" level might be a bit more
> > complex. The ring buffer has no idea of ftrace. It should not. It is at
> > a lower lever than ftrace. Although, I do think some of the protecting
> > that is done at the tracing level during resize should be moved down into
> > the ring buffer layer.
>
> Aah, so you are saying that the buffer_size file (or whatever it was called)
> is part of the ring buffer user API, and not tracing user API?

Nope, the buffer_size is part of the ftrace API. It was just that it
seemed that Ingo was pushing that the ring buffer API should handle it. I
may have misunderstood Ingo though. Note, when Ingo and I start going back
and forth, we sometimes are at the implementation level, and probably will
confuse the users ;-)

Since the buffer_size is at the ftrace level, it will make it easier to do
the changes there.

>
> But the ring buffer is just a buffer, is it meaningful to adjust a ring
> buffer size? I cannot tell tracing to go use a different buffer. And if
> there will be other users of ring buffers, they would probably want to
> have their own control over the buffer size.

Exactly.

>
> As a user, I want to adjust *the* tracing ring buffer size, not some ring
> buffer size.

Correct, and that is what you are doing.

>
> Am I making any sense? I'm trying to say that in my opinion, the
> buffer_size file does not belong to the "ring buffer" level. The upper
> levels should decide whether and how it offers buffer resizing.

The "buffer_size" file is part of ftrace, not the ring buffer. You are
making perfect sense.

-- Steve




\
 
 \ /
  Last update: 2008-12-20 03:59    [W:0.080 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site