From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Christoph Hellwig <hch@lst.de>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Li Zefan <lizf@cn.fujitsu.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Johannes Berg <johannes.berg@intel.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Tom Zanussi <tzanussi@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Andi Kleen <andi@firstfloor.org>,
Masami Hiramatsu <mhiramat@redhat.com>,
Lin Ming <ming.m.lin@intel.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
Robert Richter <robert.richter@amd.com>
Subject: Re: [RFD] Future tracing/instrumentation directions
Date: Thu, 20 May 2010 12:07:34 +0200 [thread overview]
Message-ID: <20100520100732.GD5309@nowhere> (raw)
In-Reply-To: <20100520093131.GA30929@elte.hu>
On Thu, May 20, 2010 at 11:31:31AM +0200, Ingo Molnar wrote:
> - [ While it's still a long way off, if this trend continues
> we eventually might even be able to get rid of the
> /debug/tracing/ temporary debug API and get rid of
> the ugly in-kernel pretty-printing bits. This is
> good: it may make Andrew very happy for a change ;-)
>
> The main detail here to be careful of is that lots of
> people are fond of the simplicity of the
> /debug/tracing/ debug UI, so when we replace it we
> want to do it by keeping that simple workflow (or
> best by making it even simpler). I have a few ideas
> how to do this.
How? We can emulate the /debug/tracing result with something
like perf trace, still that won't replace the immediate
availability of the result of any trace, which makes it
valuable for any simplest workflows.
> Regarding performance and complexity, which is our main
> worry atm, fortunately there's work going on in that
> direction - please see PeterZ's recent string of patches
> on lkml:
>
> 4f41c01: perf/ftrace: Optimize perf/tracepoint interaction for single events
> a19d35c: perf: Optimize buffer placement by allocating buffers NUMA aware
> ef60777: perf: Optimize the perf_output() path by removing IRQ-disables
> fa58815: perf: Optimize the hotpath by converting the perf output buffer to local_t
I would like to highlight the following commit too that _totally_
changes the requirements of our next common ring buffer, whatever it is:
c792061: perf: Disallow mmap() on per-task inherited events
Now we only need to care about local contention, we have removed the
support for buffers that contend across cpus in a single process.
Do I understand it right?
> 3) Add the function-tracer and function-graph tracer
> as an event and integrate it into perf.
>
> This will live-test the efficiency of the unification
> and brings over the last big ftrace plugin to perf.
I may start to take care of this soon.
next prev parent reply other threads:[~2010-05-20 10:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 17:51 [RFC] Unified Ring Buffer (Next Generation) Steven Rostedt
2010-05-19 18:10 ` Andi Kleen
2010-05-19 18:44 ` Steven Rostedt
2010-05-19 19:25 ` Andi Kleen
2010-05-19 19:38 ` Steven Rostedt
2010-05-19 18:47 ` Mathieu Desnoyers
2010-05-20 6:41 ` Andi Kleen
2010-05-20 13:48 ` Mathieu Desnoyers
2010-05-19 19:05 ` Mathieu Desnoyers
2010-05-20 9:31 ` [RFD] Future tracing/instrumentation directions Ingo Molnar
2010-05-20 10:07 ` Frederic Weisbecker [this message]
2010-05-20 11:07 ` Thomas Gleixner
2010-05-20 11:42 ` Ingo Molnar
2010-05-20 11:48 ` Ingo Molnar
2010-05-20 12:15 ` Frederic Weisbecker
2010-05-20 12:19 ` Theodore Tso
2010-05-20 11:36 ` Ingo Molnar
2010-05-20 13:06 ` Frederic Weisbecker
2010-05-20 14:38 ` Steven Rostedt
2010-05-20 15:04 ` Steven Rostedt
2010-05-20 20:12 ` Steven Rostedt
2010-05-21 17:49 ` Ingo Molnar
2010-05-24 20:13 ` Steven Rostedt
2010-05-21 9:24 ` Li Zefan
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=20100520100732.GD5309@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=efault@gmx.de \
--cc=gorcunov@gmail.com \
--cc=hch@lst.de \
--cc=johannes.berg@intel.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@redhat.com \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tzanussi@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.