From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 1/5] trace: do not disable wake up tracer on output of trace
Date: Thu, 22 Jan 2009 09:41:05 +0100 [thread overview]
Message-ID: <20090122084105.GD7438@elte.hu> (raw)
In-Reply-To: <20090121235805.771064570@goodmis.org>
* 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.
Ingo
next prev parent reply other threads:[~2009-01-22 8:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 23:53 [PATCH 0/5] ftrace: updates for tip Steven Rostedt
2009-01-21 23:53 ` [PATCH 1/5] trace: do not disable wake up tracer on output of trace Steven Rostedt
2009-01-22 8:41 ` Ingo Molnar [this message]
2009-01-22 9:29 ` Ingo Molnar
2009-01-22 12:02 ` Steven Rostedt
2009-01-22 12:03 ` Ingo Molnar
2009-01-21 23:53 ` [PATCH 2/5] ring-buffer: do not swap if recording is disabled Steven Rostedt
2009-01-21 23:53 ` [PATCH 3/5] trace: separate out rt tasks from wakeup tracer Steven Rostedt
2009-01-21 23:53 ` [PATCH 4/5] wakeup-tracer: show scheduling data in output Steven Rostedt
2009-01-21 23:53 ` [PATCH 5/5] ring-buffer: reset timestamps when ring buffer is reset Steven Rostedt
2009-01-22 9:32 ` [PATCH 0/5] ftrace: updates for tip Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090122084105.GD7438@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=srostedt@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox