ftrace behaviour (was: [PATCH] ftrace: introducetracing_reset_online_cpus() helper)

[Pekka Paalanen]

Steven,

I have some critique on where the tracing infrastructure has been going
to lately. Please, let me know if I am just out-of-date on the current
state or misunderstood something.

On Fri, 19 Dec 2008 12:20:18 -0500 (EST)
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> 
> On Fri, 19 Dec 2008, Fr?d?ric Weisbecker wrote:
> > 
> > 
> > That's looks good.

The mmiotrace part looks good, too.

> > 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.

But doesn't this go against the fact, that you need to write 0 there to
be able to change the ring buffer size?

I mean, is tracing_enabled a "pause button" as I recall you explaining
a long time ago, and again now, or "kill it all" as required for changing
the ring buffer size?

Or has something changed that I don't know about?

Also another important but not so related question:
are the ring buffers allocated always on boot, whenever any tracer
(say, only mmiotrace) is enabled in the kernel configuration?

The ring buffers are huge and eat a considerable chunk of precious RAM.
How could distributors ever enable mmiotrace in their kernel
configurations by default, if it eats lots of memory for nothing?

If distributors do not enable mmiotrace by default, we are in a worse
situation than with out-of-tree mmiotrace module (if it could work).
Users need to reconfigure and recompile their kernels, which is
something we wanted to avoid. This is the reality right now.

Unless you have an answer to this, I'd like to suggest we resurrect the
"none" tracer. When "none" is the current tracer, there would be no
buffers allocated at all, and you could request a new buffer size.
"none" would be the default. Do you see any problems here?

AFAIK the "nop" tracer will not do, because it still allows text
messages (markers) to be written, and hence the ring buffer must
exist. Or am I wrong?

> 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.

Does this mean I have to implement yet another on/off hook?

IMHO it is starting to be confusing having all these
current_tracer, tracing_enabled, tracing_on etc.

> I'll have to take a look at my scripts to see if that would work.
> 
> -- Steve


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/