public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anton Blanchard <anton@samba.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Soeren Sandmann <sandmann@daimi.au.dk>,
	John Levon <levon@movementarian.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, tglx@tglx.de, hpa@zytor.com
Subject: Re: [PATCH] x86: add the debugfs interface for the sysprof tool
Date: Wed, 27 Feb 2008 08:05:04 -0600	[thread overview]
Message-ID: <20080227140504.GA1435@kryten> (raw)
In-Reply-To: <20080226090223.GG9857@elte.hu>

 
Hi Ingo,

> > Anton - who has used oprofile to analyse and tune databases, JVMs,
> > 	compilers and operating systems. Maybe I've been missing out on
> > 	the killer app for all this time!!!
> 
> it's OK if you use it full time and if you are amongst the 0.001% of the 
> developer population we call "the best kernel hackers on the planet" ;-) 

I dream of being a card carrying member of the club but apparently
owning the t-shirt doesn't count :)

> It sucks badly if you use it occasionally and have to re-learn its 
> non-trivial usage and its quirks every time. As it happens, most 
> userspace developers are in this second category.
>
> (and i'm not worried about the first category at all - if needed they 
> can write their own OS from scratch ;-)

Or their own profiling infrastructure!

OK I'm done being a pain, time to be constructive. It's becoming clear
we have some work to do in order to make oprofile easier to use. I've
been involved with the project from the early days, and it's hard to be
objective when it comes to usability issues.

Off the top of my head, there are a number of reasons I think it makes
sense to use the existing oprofile kernel code instead of adding the
sysprof kernel module:

- Wide architecture support. A quick look shows 9 architectures with
  oprofile kernel module code.

- biarch support. You can mix 32 or 64bit userspace and the same oprofile
  userspace works with 32 or 64bit kernels. I'm not sure where sysprof
  sits wrt this.

- Java and Mono support. Oprofile has work underway to communicate with
  a running JVM and produce symbolic debugging information:

http://primates.ximian.com/~massi/blog/archive/2007/Nov-19.html

- Robust sample to binary mapping. It appears that sysprof has a race
  where processes can exit before the user process has a chance to do
  the PID to binary mapping.

- Support for the full set of performance monitor events. A 100 or 250Hz
  timer is useful for simple profiling, but eventually you will want
  either faster sampling or different event sampling (eg cache misses).

Oprofile now has a mode to output XML and it shouldn't take much effort
for sysprof to parse this instead of the binary debugfs file.

Anton

  parent reply	other threads:[~2008-02-27 14:09 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-19 20:37 [PATCH] x86: add the debugfs interface for the sysprof tool Arjan van de Ven
2008-02-20  9:10 ` Ingo Molnar
2008-02-26  4:13   ` Anton Blanchard
2008-02-26  8:57     ` Ingo Molnar
2008-02-20 18:16 ` Peter Zijlstra
2008-02-20 18:39   ` Arjan van de Ven
2008-02-20 18:53     ` Peter Zijlstra
2008-02-20 18:58       ` Peter Zijlstra
2008-02-26  5:03         ` Anton Blanchard
2008-02-20 19:26       ` Arjan van de Ven
2008-02-20 20:58         ` Peter Zijlstra
2008-02-20 21:07           ` Arjan van de Ven
2008-02-20 21:44             ` Peter Zijlstra
2008-02-20 22:36               ` Arjan van de Ven
2008-02-23  8:11 ` Andrew Morton
2008-02-23 11:37   ` Ingo Molnar
2008-02-23 13:53     ` John Levon
2008-02-23 15:50       ` Ingo Molnar
2008-02-23 20:15       ` Soeren Sandmann
2008-02-23 20:42         ` Andrew Morton
2008-02-26  5:13         ` Anton Blanchard
2008-02-26  9:02           ` Ingo Molnar
2008-02-26 17:29             ` Andrew Morton
2008-02-27 14:05             ` Anton Blanchard [this message]
2008-02-24 13:10       ` Theodore Tso
2008-02-24 13:44         ` Ingo Molnar
2008-02-24 14:33           ` Ingo Molnar
2008-02-24 16:32         ` John Levon
2008-02-24 18:19           ` Theodore Tso
2008-02-23 18:40     ` Andrew Morton
2008-02-23 11:51   ` Pekka Enberg
2008-02-23 12:22     ` Ingo Molnar
2008-02-23 12:29       ` Pekka Enberg
2008-02-23 18:46     ` Andrew Morton
2008-02-24  2:49       ` Pekka Enberg
2008-02-24  3:12         ` Nicholas Miell
2008-02-26  6:27           ` Pekka Enberg
2008-02-26  6:48             ` Pekka Enberg
2008-02-26  8:55               ` Ingo Molnar
2008-02-23 14:54   ` Pekka Enberg
2008-02-23 19:01     ` Andrew Morton

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=20080227140504.GA1435@kryten \
    --to=anton@samba.org \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=levon@movementarian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sandmann@daimi.au.dk \
    --cc=tglx@tglx.de \
    /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