From: Frederic Weisbecker <fweisbec@gmail.com>
To: David Sharp <dhsharp@google.com>
Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>,
Paul Menage <menage@google.com>, Li Zefan <lizf@cn.fujitsu.com>,
Stephane Eranian <eranian@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Michael Rubin <mrubin@google.com>, Ken Chen <kenchen@google.com>,
linux-kernel@vger.kernel.org,
containers@lists.linux-foundation.org
Subject: Re: [RFC] tracing: Adding cgroup aware tracing functionality
Date: Thu, 7 Apr 2011 23:32:12 +0200 [thread overview]
Message-ID: <20110407213208.GE1798@nowhere> (raw)
In-Reply-To: <BANLkTim70Ef0gy+W+4h76PABn32wDRvTtw@mail.gmail.com>
On Thu, Apr 07, 2011 at 01:22:30PM -0700, David Sharp wrote:
> On Thu, Apr 7, 2011 at 5:06 AM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> Perf doesn't have the same latency characteristics as ftrace. It costs
> a full microsecond for every trace event.
>
> https://lkml.org/lkml/2010/10/28/261
>
> It's possible these results need to be updated. Has any effort been
> made to improve the tracing latency of perf?
Nothing significant since then, I believe. But the hotspots are known
and some are relatively low hanging fruits if you want to get closer to
ftrace throughput:
* When an event triggers, we do a double copy. A first one in a temporary
buffer and a second one from the temporary buffer to the event'ss one.
This is because we don't have the same discard feature than in ftrace
buffer. We need to first filter on the temporary buffer and give up if the filter
matched instead of copying to the main buffer.
As a short term solution: have a fast path tracing for the case where we
don't have a filter: directly copy to the main buffer.
In the longer term I think we want to filter on tracepoint parameters
rather than in the ending trace.
* We save more things in perf, because we have the perf headers. So we
save the pid twice: once in trace event headers, second in perf headers.
We need to drop the one from the trace event.
Also in the case of pure tracing, we don't need to save the ip in the perf
headers.
* We have lots of conditionals in the fast path, due to some exclusion options,
overflow count tracking, etc... We probably want a fastpath tracing function
for the high volume tracing case, something that goes quickly to the buffer
saving.
And there are things common to ftrace and perf that we probably want to have:
like tracking of pids using sched switch event if one is running, instead
of saving the pid on each traces. And get rid of the preempt_count in the
trace event headers, at least have the possibility to choose whether we want
it.
Any help in any of these tasks would be very welcome.
next prev parent reply other threads:[~2011-04-07 21:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-06 18:50 [RFC] tracing: Adding cgroup aware tracing functionality Vaibhav Nagarnaik
2011-04-07 1:33 ` Frederic Weisbecker
2011-04-07 3:17 ` Vaibhav Nagarnaik
2011-04-07 12:06 ` Frederic Weisbecker
2011-04-07 20:22 ` David Sharp
2011-04-07 21:32 ` Frederic Weisbecker [this message]
2011-04-07 22:42 ` David Sharp
2011-04-08 0:28 ` Frederic Weisbecker
2011-04-08 7:37 ` Steven Rostedt
2011-04-08 13:45 ` Frederic Weisbecker
2011-04-08 14:07 ` Peter Zijlstra
2011-04-08 18:32 ` Michael Rubin
2011-04-08 20:27 ` Justin TerAvest
2011-04-08 14:07 ` Peter Zijlstra
2011-04-08 17:02 ` Steven Rostedt
2011-04-09 11:08 ` Peter Zijlstra
2011-04-08 19:00 ` Frederic Weisbecker
2011-04-08 20:38 ` Frederic Weisbecker
2011-04-08 21:41 ` David Sharp
2011-04-12 21:38 ` Frederic Weisbecker
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=20110407213208.GE1798@nowhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=dhsharp@google.com \
--cc=eranian@google.com \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=mrubin@google.com \
--cc=rostedt@goodmis.org \
--cc=vnagarnaik@google.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