Perfcounters added to the mainline
Posted Jul 3, 2009 6:56 UTC (Fri) by graydon (guest, #5009)
- 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?
Posted Jul 3, 2009 9:04 UTC (Fri) by njs (guest, #40338)
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...
Posted Jul 10, 2009 14:36 UTC (Fri) by oak (guest, #2786)
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