Re: [PATCH 0/26] oprofile: Performance counter multiplexing

[Pekka Enberg <penberg@cs.helsinki.fi>]

Hi Robert,

On Wed, Aug 5, 2009 at 3:35 PM, Robert Richter<robert.richter@amd.com> wrote:
> The question is more if it makes sense. It's new to me dropping
> user/kernel interfaces that are in use and forcing its developers to
> rewrite their code. Oprofile is actively developed and in many
> distros. It supports architectures perfcounters doesn't. So, what do
> you want?

Maybe we can keep the ABIs in place but use a common machinery under
the hood for both perf and oprofile? That said, I do expect oprofile
ABIs to be special meaning that there's probably not a whole lot users
other than the oprofile user-space tool? So if do convert the
user-space tool to use sys_perf_counter_open() and put the in-kernel
oprofile code into deep-maintenance mode, maybe we can eventually get
rid of it?

That said, the lack of architecture support for perf is definitely a
blocker here...

On Wed, Aug 5, 2009 at 3:35 PM, Robert Richter<robert.richter@amd.com> wrote:
> And why not having more than one profiling subsystem in the kernel? I
> see also more than one type of car on the street though all of them
> have 4 wheels.

Well, so far I've only had bad experiences with duplicate
functionality in the kernel be it a core kernel subsystem like slab or
a device driver (broadcom and e100 come to mind). The problem is that
you fragment tester and developer base and end up with a different set
of bugs for each of the duplicate components causing more work than
necessary. And what eventually happens is that you have only one
component that's under active development but you can't get rid of the
less active ones because people depend on them and the active one has
corner case bugs that just don't get fixed.

                        Pekka