linux-kernel - Re: [PATCH] x86: add the debugfs interface for the sysprof tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 27 Feb 2008 08:05:04 -0600
From:	Anton Blanchard <anton@...ba.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Soeren Sandmann <sandmann@...mi.au.dk>,
	John Levon <levon@...ementarian.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, tglx@...x.de, hpa@...or.com
Subject: Re: [PATCH] x86: add the debugfs interface for the sysprof tool

 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/