Messages in this thread | | | Date | Fri, 8 May 2009 21:43:03 +0800 | From | Wu Fengguang <> | Subject | Re: ftrace: concurrent accesses possible? |
| |
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
| |