From: Maynard J. <may...@us...> - 2010-05-06 16:34:03
|
On 05/04/2010 10:02 AM, Linus Torvalds wrote: > > > On Tue, 4 May 2010, Robert Richter wrote: >> >> Hmm, maybe it was not optimal this way, but at least it worked. > > oprofile _should_ have given you the "architectural" counters even without > that patch. If ppro_init() fails, and the CPU supports arch_perfmon (which > model-30 most certainly should do), it should fall back on > > i386/arch_perfmon > > as the cputype string. And oprofile should then happily use all the common > profile events (ie profiling by cycle etc). > > That said, I would suggest you stop using oprofile. It's a total piece of > sh*t how it tries to match those idiotic string names to anything. That > interface is _fundamentally_ broken, and can never work for new models, > and by "new", I obviously mean "anything more recent than about two years" > going by past experience. > > The "perf" tools are way more pleasant to use - they have a better > interface, a saner setup, and they give much more useful information. Admittedly, the perf tool has some distinct advantages over oprofile -- most notably, the ability to profile a user's application without needing root authority. But IMHO, perf is not a ready replacement for oprofile at this time. Here are some of the gaps between perf and oprofile (that I'm aware of): 1. perf does support native events, but right now, it's not user friendly -- the user needs to know the appropriate hex code value that corresponds to each native event. 2. perf-report does not output XML. There are multiple GUI tools available that make use of oprofile XML output. 3. perf has no mechanism for archiving sample data and binaries for off-line analysis. 4. perf has no corollary to oprofile's opimport utility -- useful for offline analysis on a different architecture from the profiled system (typically used with embedded systems). 5. perf has no capability for profiling JITed code (Java is the only language officially supported by oprofile right now). 6. perf doesn't have a "diff" feature to show side-by-side differences between two profile runs. Could these limitations in perf be fixed? Certainly. Can oprofile be made better, in particular, changing over to using the kernel's Performance Events subsystem and enabling non-root access? You bet! But the question is "where do we apply limited resources?" The fact that perf is part of the kernel has both advantages and disadvantages. I suspect most performance tool users and contributors are not regular followers of LKML. For a newbie or occasional user, posting a question or a patch to any list can be a bit intimidating. When you have to go through the LKML versus a small project mailing list, that intimidating hurdle is awfully high. For this reason, I don't think you'll ever get the kind of widespread community involvement with perf that oprofile has enjoyed over the years. There are many different kinds of performance tools for Linux, from the most basic to the very elaborate. perf does not need to be the be-all and end-all of performance tools. oprofile and other performance tools still have a place in the world. -Maynard > > Linus > > ------------------------------------------------------------------------------ > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |