User: Password:
Subscribe / Log in / New account



Posted Dec 10, 2008 16:16 UTC (Wed) by graydon (guest, #5009)
In reply to: Oprofile by zooko
Parent article: Dueling performance monitors

The original article is incorrect when it says "there has never been support for this kind of performance monitoring in the mainline kernel". Oprofile provides access to these performance counters already, and has since mid-2.5 development. I use it every few days on stock 2.6 distro kernels. It doesn't provide, say, the BTS and PEBS buffers; but you usually don't have to go quite that far down. If you're looking for hotspots in terms of CPI, bus traffic, unusual FPU conditions, cache miss or branch mispredict counters, you're just fine with oprofile.

Perfmon is a separated "drivers and API only" layer that you can run various profilers and tools on top of. It also gets you a little further into the really hairy monitoring hardware (PEBS/BTS), beyond the event counters. Essentially it's the layer of very machine-dependent guts that (proprietary) vtune and (free) oprofile both duplicate parts of, along with a rich programmatic interface. You can run oprofile on top of perfmon if you like. Or the two can simply co-ordinate their access to the same performance counters.

For normal developers, this is mostly all plumbing. If you want to work with hardware performance counters, you've been able to via oprofile on normal linux machines for the past 5 years or so (IIRC it landed early 2003). Current oprofiles have all sorts of additional higher-level machinery (call graph profiling, a JIT API, the ability to work with xen domains, etc.)

(Log in to post comments)


Posted Dec 10, 2008 17:14 UTC (Wed) by fuhchee (guest, #40059) [Link]

If anything, the ingo/gleixner scheme seems to be solely a sampling-oriented tool, and thus in reality more of a competitor to oprofile than to perfmon.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds