Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper)

[Pekka Paalanen <pq@iki.fi>]

On Fri, 19 Dec 2008 20:46:38 -0500 (EST)
Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> On Sat, 20 Dec 2008, Pekka Paalanen wrote:
> 
> > On Fri, 19 Dec 2008 19:29:30 -0500 (EST)
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > I thought this was just about not having to do
> > 
> > $ echo 0 > tracing_enabled
> > $ echo 28764243 > buffer_size
> > $ echo 1 > tracing_enabled
> > 
> > and instead just do
> > 
> > $ echo 28764243 > buffer_size
> > 
> > which would do exactly the same, except being easier for the user.
> > Personally I've never dreamed of any kind of resize-in-flight.
> > 
> 
> 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?

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.

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

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.

-- 
Pekka Paalanen
http://www.iki.fi/pq/