Re: [tracing, hang] dumping events gets stuck in synchronise_sched

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2010-08-18 at 10:55 +1000, Dave Chinner wrote:
> On Tue, Aug 17, 2010 at 07:07:11PM -0400, Steven Rostedt wrote:

> > You mean because it uses synchronize_sched() it should be removed? Seems
> > that it was another kernel bug that caused the issue.
> 
> Right now I'm using the trace file for exactly what the docuemntation
> says it should be used for, but it hangs. You're saying that the
> interface is effectively redundant because there's a trace_pipe
> interface that shouldn't hang and I should use that instead.

trace_pipe consumes the data as trace does not.

> 
> Debug interfaces should be reliable in the face of common problems -
> a system burning a CPU in a tight loop is a pretty common problem.
> That leads to three options: either fix the hang, document the fact
> that the trace file is not reliable and that you should use other
> interfaces, or remove the interface altogether.

I could update the documentation to warn that the trace file uses the
common utility "synchronize_sched()" and that if you are debugging a
system that has a CPU out of commission, not to use it because,
synchronize_sched() will never return. If you need to debug this case,
then use trace_pipe which will consume all data, but is made for live
reads and does not use synchronize_sched().

But the tracer is used for more than just debugging. I use it for
analyzing system behavior, and not to debug anything, which I use the
trace file for all the time. I usually enable tracing, disable it, then
look at the trace file. For any live tracing, trace_pipe should be used.
If I had not documented that, I should go back and do so.

-- Steve