All of lore.kernel.org
 help / color / mirror / Atom feed
From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chase Douglas <chase.douglas@canonical.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
	Soeren Sandmann <sandmann@daimi.au.dk>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, kernel-team@lists.ubuntu.com
Subject: Re: Tracing configuration review
Date: Thu, 27 May 2010 16:50:44 +0530	[thread overview]
Message-ID: <20100527112044.GA2713@in.ibm.com> (raw)
In-Reply-To: <20100525230656.GD5370@nowhere>

On Wed, May 26, 2010 at 01:06:57AM +0200, Frederic Weisbecker wrote:
> On Tue, May 25, 2010 at 05:09:59PM -0400, Chase Douglas wrote:
> > On Tue, 2010-05-25 at 22:13 +0200, Frederic Weisbecker wrote:
> > > On Tue, May 25, 2010 at 03:31:46PM -0400, Chase Douglas wrote:

<snipped>

> > > IMO, it is deprecated. The perf interface is much more powerful and flexible.
> > > Prasad, do you agree if I remove this ftrace plugin?

Sure, go ahead.

> > 
> > If there isn't any use in enabling it due to perf's features, then we
> > can turn it off. However, if there's any use to be gained by this over
> > perf's features, then I'd prefer to leave it on. Thoughts?
> 
> 
> 
> No, perf does much more:
> 
> - stacktraces recording
> - "top" alike view with perf top
> - stat with perf stat, etc...
> - userspace memory accesses
> 
> 
> Here is a quick example:
> 
> $ cat test.c
> int var;
> 
> void func_c(void)
> {
> 	var++;
> }
> 
> void func_b(void)
> {
> 	func_c();
> }
> 
> 
> void func_a(void)
> {
> 	func_c();
> }
> 
> 
> int main(int argc, char **argv)
> {
> 	int i;
> 
> 	for (i = 0; i < 1000; i++)
> 		if (i % 2)
> 			func_a();
> 		else
> 			func_b();
> 
> 	return 0;
> }
> //end test.c
> 
> $ gcc test.c -fno-omit-frame-pointer -o test
> 
> $ readelf -s test | grep var
>     74: 000000000060102c     4 OBJECT  GLOBAL DEFAULT   25 var
> 
> $ perf record -g -c 1 -e mem:0x000000000060102c:w ./test
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.069 MB perf.data (~3020 samples) ]
> 
> $ perf report
> 
> # Events: 1K cycles
> #
> # Overhead  Command      Shared Object  Symbol
> # ........  .......  .................  ......
> #
>     99.90%     test  test               [.] func_c
>                |
>                --- func_c
>                   |          
>                   |--49.95%-- func_a
>                   |          |          
>                   |          |--99.60%-- main
>                   |          |          __libc_start_main
>                   |           --0.40%-- [...]
>                   |          
>                   |--49.85%-- func_b
>                   |          main
>                   |          |          
>                   |          |--99.60%-- __libc_start_main
>                   |           --0.40%-- [...]
>                    --0.20%-- [...]
> 
> 
> To sum up, there is nothing the ksym tracer does that perf can't.
> 

I second Frederic's opinion on this. 

Thanks,
K.Prasad

> Well, may be perf doesn't offer the time ordered view of memory
> accesses, I must confess. Although this is still something we can
> easily provide if people want it.
> 

  reply	other threads:[~2010-05-27 11:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-25 19:31 Tracing configuration review Chase Douglas
2010-05-25 19:46 ` Steven Rostedt
2010-05-25 19:58   ` Chase Douglas
2010-05-25 20:20     ` Frederic Weisbecker
2010-05-25 20:17   ` Frederic Weisbecker
2010-05-25 22:01     ` Steven Rostedt
2010-05-25 23:13       ` Frederic Weisbecker
2010-05-26 10:57     ` [Patch] tracing: remove boot tracer Américo Wang
2010-05-26 15:49       ` Frederic Weisbecker
2010-05-25 20:13 ` Tracing configuration review Frederic Weisbecker
2010-05-25 21:09   ` Chase Douglas
2010-05-25 23:06     ` Frederic Weisbecker
2010-05-27 11:20       ` K.Prasad [this message]
2010-05-27 22:15         ` Frederic Weisbecker
2010-06-08 17:35     ` Randy Dunlap
2010-06-08 22:00       ` Chase Douglas
2010-06-11 21:51         ` Randy Dunlap
2010-06-14  2:41           ` Chase Douglas
2010-05-26  6:19   ` Pekka Enberg
2010-05-26  7:20     ` Li Zefan
2010-05-26  7:44       ` Pekka Enberg
2010-05-26  8:42       ` Eduard - Gabriel Munteanu
2010-05-26  9:12         ` 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=20100527112044.GA2713@in.ibm.com \
    --to=prasad@linux.vnet.ibm.com \
    --cc=chase.douglas@canonical.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=fweisbec@gmail.com \
    --cc=kernel-team@lists.ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=rostedt@goodmis.org \
    --cc=sandmann@daimi.au.dk \
    /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.