[lkml]   [2009]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/26] oprofile: Performance counter multiplexing

* Robert Richter <> wrote:

> On 03.08.09 13:22:20, Ingo Molnar wrote:
> >
> > Now i'm also co-maintaining perfcounters and because it's a full
> > oprofile replacement (which aspect Robert seems to disagree with
> > ;-)
> I can't imagine a full oprofile replacement. This would require a
> rewrite of all userland tools and also the complete port of all
> architectures (which has to be done for each architecture
> individually). And first of all, I don't think it is necessary to
> do this, why not keep different interfaces for different purposes?

Perfcounters and tools/perf/ intends to be everything that oprofile
is - just implemented in a better way. What 'different purposes' do
you mean?

Lets admit it: the oprofile kernel-side code has been mis-designed
from the get go and it is unfixable in its current form. The
mis-design is hardcoded in the oprofile ABIs and into portions of
the oprofile tooling. If you wanted to fix that you'd have to
rewrite the whole thing from scratch.

And the thing is, we already did that: the 'fix' for oprofile is
perfcounters and the perf tool ;-) This is why we developed and
merged perfcounters upstream and did not extend oprofile to begin

All in one, Oprofile is largely obsolete and i dont see that
realization from your patches. I see a lot of ongoing churn coming
up on the oprofile kernel side and i'm not sure i want to assist
that, because i think it's stupid and i dont like doing or helping
stupid things.

So please either convince me that it's not obsolete, or lets state
it as a fundamental disagreement that you dont think that oprofile
is obsolete and that you still want to develop it.


 \ /
  Last update: 2009-08-04 19:09    [W:0.071 / U:0.804 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site