Messages in this thread | | | Date | Fri, 19 Dec 2008 23:05:56 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 19 Dec 2008, Fr?d?ric Weisbecker wrote: > > > > > > That's looks good. > > By the past, I also suggested Steven to automatically reset the traces > > buffer each time a tracer is started, that > > would factor out the code a bit more. I don't think one tracer would > > avoid to reset the buffer once it is started, and > > I don't think it is needed to reset twice on tracer switching: on stop > > of the old tracer and on start on the new. Only > > on start should be enough. > > I'm actually against the idea of reseting a trace everytime we enable it. > That is: > > echo 1 > /debug/tracing/tracing_enabled > > This should not reset the tracer. I actually do tracing where I disable > and enable it around areas I am interested in. I want all tracing, not > just the last one. > > Now we have recently added /debug/tracing/tracing_on which can quickly > stop tracing. I may be able to use that, and we can let the > tracing_enable" reset it too. > > I'll have to take a look at my scripts to see if that would work.
yep, using /debug/tracing/tracing_enabled is the right model to quickly toggle tracing without losing the buffer.
The 'switch tracer' op is really a slow thing anyway. It can involve unpatching/repatching functions, etc. etc. - and while it works, it shouldnt really be encouraged as a dynamic tool coding pattern.
Ingo
| |