lkml.org 
[lkml]   [2009]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ftrace: concurrent accesses possible?

On Fri, 8 May 2009, Wu Fengguang wrote:

> Hello,
>
> On Fri, May 08, 2009 at 07:47:42PM +0800, Ingo Molnar wrote:
> >
> > So this should be done in cooperation with instrumentation folks,
> > while improving _all_ of Linux instrumentation in general. Or, if
> > you dont have the time/interest to work with us on that, it should
> > not be done at all. Not having the resources/interest to do
> > something properly is not a license to introduce further
> > instrumentation crap into Linux.
>
> I have a dummy question on /debug/trace: is it possible to
> - use 2+ tracers concurrently?

Two plugins? no.

Two types of tracing? yes.

The "current_tracer" is for specific tracing purposes that like, latency
tracing, function tracing and graph tracing. There are others, but they
are more "themes" than tracers. The latency tracing only shows a "max
latency" and does not show current traces unless they hit the max
threshold. The function graph tracer has a different output format that
has indentation based on the depth of the traced functions.

But with tracing events, we can pick and choose any event and trace them
all together. You can filter them as well. For new events in the kernel,
we only add them via trace events. These events show up in the plugin
tracers too.

> - run a system script that makes use of a tracer,

Sure

> without disturbing the sysadmin's tracer activities?

Hmm, you mean have individual tracers tracing different things. We sorta
do that now, but they are more custom. That is, you can have the stack
tracer running (recording max stack of the kernel) and run other tracers
as well, without noticing. But those that write to the ring buffer, only
write to a single ring buffer. If another trace facility created their own
ring buffer, then you could have more than one ring buffer being used. But
ftrace currently uses only one (This is net exactly true, because the
latency tracers have a separate ring buffer to store the max).

> - access 1 tracer concurrently from many threads,

More than one reader can happen, but inside the kernel, they are
serialized. When reading from the trace_pipe (consumer mode), every read
will produce a different output, because the previous read was "consumed".
If two threads try to read this way at the same time, they will each get a
different result.

> with different filter etc. options?

Not sure what you mean here. If you two threads filtering differently,
this should be done in userspace.

-- Steve

>
> If not currently, will private mounts be a viable solution?



\
 
 \ /
  Last update: 2009-05-08 15:19    [W:0.216 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site