Messages in this thread | | | Date | Sat, 20 Dec 2008 04:32:10 +0200 | From | Pekka Paalanen <> | Subject | Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper) |
| |
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/
| |