Re: ftrace: concurrent accesses possible?

[Wu Fengguang <fengguang.wu@intel.com>]

On Fri, May 08, 2009 at 09:17:04PM +0800, Steven Rostedt wrote:
> 
> 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.

OK. Thanks for explaining!

> > - 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 

Right. Plus two 'instances' of the same tracer run with different options.

> 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).

That's OK.

> > - 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.

It's about efficiency.  Here is a use case: one have N CPUs and want
to create N threads to query N different segments of the total memory
via kpageflags. This ability is important for a large memory system.

Thanks,
Fengguang