[lkml]   [2008]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online_cpus() helper)

    thank you for a complete reply. Few comments below.

    On Fri, 19 Dec 2008 19:03:42 -0500 (EST)
    Steven Rostedt <> wrote:

    > On Sat, 20 Dec 2008, Pekka Paalanen wrote:
    > > 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?
    > It is more now a pause than kill it all. Although it never really did
    > kill it all. Before the ring buffer, we needed to echo in 'none' to
    > the current tracer before resizing. Now we can just get by with echoing 0
    > to the tracing_enabled.

    I guess I don't really see what was so bad about switching to the "none"
    tracer, as the resize operation is expected wipe everything anyway.
    Likely because for mmiotrace, toggling tracing_enabled is the same as
    switching tracers.

    > I'm starting to like the idea that tracing_enabled is a lighter weight
    > version of echoing the the tracer into the current_tracer file. Perhaps it
    > should reset the buffer on a echo 1 > tracing_enabled. We now have a
    > tracing_on that we can "pause" tracing with. The only thing that the
    > tracing_on does is to stop writes to the ring buffer. It does not stop any
    > of the infrastructure that does the tracing.
    > Note, this is the main reason why you need to check for NULL on return of
    > a ring_buffer_lock_reserve. That will return NULL when the tracing_on is 0.
    > > 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?
    > Hmm, good point. We could change the allocation to when it is first
    > enabled. Something other than 'nop' being put into the current_tracer
    > file.

    I'm very much looking forward to this.

    > >
    > > 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?
    > No, you are quite right. We could recreate the 'none' tracer again that
    > has no buffer. At boot up it would be the default tracer, unless something
    > else changes that.

    The "nop" having no buffers at boot would be enough, but this would be
    even better.

    > >
    > > > 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?
    > Nope, the on/off hook is extremely fast, and the plugins do not even know
    > when they happen. The on/off simply turns off writing to the ring buffer.
    > The plugin functions will still be called, it is just that they will fail
    > to write to the ring buffers. As stated above, the
    > ring_buffer_reserve_lock will return a NULL.

    Does this also increment the lost events counters?

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

    > The tracing_enabled is the way to start and stop a trace. I'm considering
    > to implement Frederic's request to reset the buffer on enabled. This is
    > quick but requires locks and mutexes to be taken. It calls a hook to the
    > plugin because different plugins actually want to reset (the irq latency
    > tracers reset with this).
    > The tracing_on is something that has been asked by developers to give a
    > way to start and stop tracing fast as possible, with no mutexes or added
    > locks. In fact, this option is local to the ring buffer code. Ftrace does
    > not even use it directly. It just a global flag to stop tracing. There's
    > also an in-kernel equivalent tracing_on() and tracing_off(). This just
    > sets or clears a global flag that will stop any more writes to the trace
    > buffer.

    Why not call tracing_on, say, logging_enabled?
    IMHO tracing_enabled vs. tracing_on is incomprehesible, but
    tracing_enabled vs. logging_enabled is a little more understandable.
    current_tracer is self-explanatory, and tracing_enabled used to be.


    Pekka Paalanen

     \ /
      Last update: 2008-12-20 03:21    [W:0.026 / U:0.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site