lkml.org 
[lkml]   [2009]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] trace: do not disable wake up tracer on output of trace

On Thu, 22 Jan 2009, Ingo Molnar wrote:

>
> * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > From: Steven Rostedt <srostedt@redhat.com>
> >
> > Impact: fix to erased trace output
> >
> > To try not to have the outputing of a trace interfere with the wakeup
> > tracer, it would disable tracing while the output was printing. But if a
> > trace had started when it was disabled, it can show a partial trace. To
> > try to solve this, on closing of the tracer, it would clear the trace
> > buffer.
> >
> > The latency tracers (wakeup and irqsoff) have two buffers. One for
> > recording and one for holding the max trace that is printed. The
> > clearing of the trace above should only affect the recording buffer. But
> > for some reason it would move the erased trace to the print buffer.
> > Probably due to a race with the closing of the trace and the saving ofhe
> > max race.
>
> hm, that race needs to be fixed then.
>
> > The above is all pretty useless, and if the user does not want the
> > printing of the trace to be traced itself, then the user can manual
> > disable tracing. This patch removes all the code that tries to keep the
> > output of the tracer from modifying the trace.
>
> printing of the trace should not be traced. I cannot imagine any usage
> mode where that would be interesting - and i can imagine a ton of cases
> where users would be confused/distracted by the tracer in essence zapping
> their measurement by replacing it with some uninteresting 'the tracer
> itself has wakeup delays' data.
>
> auto-disabling latency tracing while the trace is being output is
> essential. Measurement should never impact the workload that is being
> measured.
>
> We should fix that race instead.

Well actually, I don't see the output causing any issues. That's another
point. Should we work on adding all this complex code for something that
might not every cause an issues? I added it because it did cause an issue
with the irqs off traces, although I'm not sure that is true any
more either. I just added it to the wakeup tracer just to be consistent.

With the new trace_off switch that disables the ring buffer, and the
stopping of the swap buffers with the switch off, I do not think that this
code is even necessary anymore.

I think I'll rip out the code from irqsoff and see if it is still an issue
there. If not, I think we can get rid of it.

-- Steve



\
 
 \ /
  Last update: 2009-01-22 13:05    [W:0.423 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site