User: Password:
Subscribe / Log in / New account

Perfcounters added to the mainline

Perfcounters added to the mainline

Posted Jul 3, 2009 4:14 UTC (Fri) by njs (guest, #40338)
Parent article: Perfcounters added to the mainline

Does anyone know what is meant about oprofile being an "abject failure"? (This is an honest question, I use it all the time and for my use it's awesome.)

(Log in to post comments)

Perfcounters added to the mainline

Posted Jul 3, 2009 6:56 UTC (Fri) by graydon (guest, #5009) [Link]

Caveat: I use oprofile every couple of days, and I helped write some of the drivers for it. Still, I'm sympathetic to complaints about it. From what I've observed:

- There's a lot of drift between userspace and kernelspace. Event names and communication mechanisms seem to change from release to release. I've had to edit the shell scripts and source code repeatedly on installed versions.

- Apparently the kernel people wanted a much faster cycle time on new hardware support, and oprofile userspace is "lightly maintained". This hasn't been as much of a problem for me since I stay behind the curve intentionally, and mostly just want to monitor clocks, CPI, and crude cache and branch-mispredict hotspots; but I also know where to patch in userspace if necessary.

- There is further drift against libbfd, gcc, and the various toolchain pieces involved in mapping samples to reasonable debug information. I don't expect the kernel developers to do much more on this than snark about how userspace sucks; but who knows, maybe they'll write another toolchain and be free at last.

- The drift has been sufficiently bad that most non-kernel, non-oprofile developers on linux I talk to have no idea how to "get oprofile working" and need to be hand-held through it. And when they do get it working and it suddenly stops (or lies, which it can do if the drift is *just shy* of enough to break it), they don't know how to fix it.

- As an additional data point, I've seen two (perhaps three now?) separate projects spring up that ship *both* their own batch of replacement userspace tools *and* their own forked copy of the oprofile kernel module, in order to keep the interface, expectations and capabilities pinned down.

All that aside though, I really do use oprofile all the time and find it (and kcachegrind) *way* more useful for performance tuning than, say, shark or vtune. Totally worth the price of admission. The other-platform competition seems to lie, crash, wedge, and otherwise misbehave even worse.

Maybe there were some other complaints I missed?

Perfcounters added to the mainline

Posted Jul 3, 2009 9:04 UTC (Fri) by njs (guest, #40338) [Link]

Thanks for the explanation. On further thought, the tools *could* be somewhat better. I do now recall stalking people in #oprofile a few years ago to get them to explain what some of the output fields actually were, and the upstream oprofile-to-kcachegrind script is ~useless. (But then, that's partly my fault for not sending patches. I wouldn't want to live with oprofile long without real call tree visualization.)

That doesn't seem like the sort of thing the kernel folks would deign to notice, though.

Certainly it makes sense in general to keep coupled tools together, to reduce drift and lower the barrier to entry. When it comes to maintaining an ABI, though, I think I trust the kernel folks (when they decide they care) a bit more than binutils...

Perfcounters added to the mainline

Posted Jul 10, 2009 14:36 UTC (Fri) by oak (guest, #2786) [Link]

> the upstream oprofile-to-kcachegrind script is ~useless ...
> I wouldn't want to live with oprofile long without real call tree

Because of that, I've used this:

(Not as nice as having Kcachegrind + code browsing, but mostly good

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