lkml.org 
[lkml]   [2015]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2015-11-03 00:41    [W:0.059 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site