Messages in this thread | | | Date | Mon, 2 Nov 2015 18:12:15 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 2/3] ftrace: add ftrace-buffer option |
| |
On Mon, 2 Nov 2015 23:01:08 +0000 (UTC) Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> ----- On Nov 2, 2015, at 5:56 PM, rostedt rostedt@goodmis.org wrote: > > > On Mon, 2 Nov 2015 17:42:43 -0500 > > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > > >> In order to use ftrace tracers to generate tracepoints without doing > >> tracing to its own hardcoded ring buffers, add a ftrace-buffer option > >> (default: 1). When set to 0, it disables tracing into the ftrace > >> hardcoded buffers. > >> > > > > This needs a more in depth change log. I have no idea why this is > > needed. > > I can do an updated change log. This is needed for the next patch > in this series, which adds tracepoints in the ftrace irqs and preempt > off tracer, so other tracers such as Perf and LTTng can use them. > > > > > Also, the trace_options code have been redesigned, and this won't apply > > to it (see linux-next). > > I can rebase my work on top of linux-next if you are OK with > the general idea. > > > Also, if this is only for irqsoff latency > > tracers, it should be a tracer option, not a global one. > > I've currently only done the irqsoff latency tracer > part, but I'm wondering whether: > > 1- we should make it a irqsoff latency tracer option, > 2- we should keep it as a global ftrace option, and apply it to > other ftrace tracers as well, > > Thoughts ? > >
Tomorrow I'll take a deeper look at patch 3 to try to understand.
-- Steve
| |