lkml.org 
[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/6] ftrace: port to the new ring_buffer

* Steven Rostedt <rostedt@goodmis.org> wrote:

> These patches are against linux-tip.
>
> The first is just a fix in the wakeup selftest.
>
> The next is a port of the Unified tracer buffer to linux-tip and some
> updates.
>
> After that is the ftrace port to use the ring buffer, followed by some
> more enhancements to ftrace because of the new variable length buffer.
>
> I tried a few configurations and tried to test all the different
> ftrace tracers, but I'm sure there may be some bugs still to work out.
> I worked out all those that I found.

very nice! I'd expect breakages and complications too so i restructured
tip/tracing/* a bit: firstly i created a tip/tracing/core append-only
merge branch which collects all the known-robust bits. Then i created a
new branch for your new generic ring-buffer feature:
tip/tracing/ring-buffer, and applied your patches. I've started testing
it.

Once we declare it OK, it can be merged into tip/tracing/core.

> But, with the ring_buffer I can envision several ways to clean up
> ftrace and to make adding new tracers cleaner.
>
> I'm also thinking about making a way that each tracer can allocate its
> own buffer, and allow for more than one tracer to be running at the
> same time! (only with different buffers).

yeah. Ideally this should just fall out of the generic framework - i.e.
tracer plugins should not have to do anything extra to get per tracer
buffers. They should just add their own specialistic flavor, there
should be no repetitions otherwise. (barring cases where a tracer wants
to deviate from default behavior)

Ingo


\
 
 \ /
  Last update: 2008-09-30 09:53    [W:0.089 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site