Messages in this thread | | | Date | Thu, 13 Aug 2009 18:13:40 +0200 | From | Robert Richter <> | Subject | Re: [PATCH 0/26] oprofile: Performance counter multiplexing |
| |
On 06.08.09 12:51:34, Ingo Molnar wrote: > > * Pekka Enberg <penberg@cs.helsinki.fi> wrote: > > > 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? > > Note, we dont need to (and dont want to) 'get rid of oprofile' - > that's not the point. Nobody is arguing for instant removal of > oprofile.
This sound good to me...
> All i'm arguing for is to not rewrite all oprofile drivers while we > try to extend perfcounters support. Robert's series does exactly > that and that's where my unhappiness comes from ... > > As you note it below, in terms of development it's quite a > distraction to have active development in both facilities, when > oprofile is arguably on the to-be-obsoleted side of the equation.
Ingo, you can be sure, future implementations will keep the focus on perfcounters. A single pmu implementation is that I prefer too, it reduces development and testing efforts.
> Converting the user-space oprofile tools: instead of some in-kernel > wrappery, the right approach is to use the already existing high > level interface: to use sys_perf_counter_open() in the oprofile > daemon. > > It only affects the sample collection daemon (which is a small > portion of oprofile user-space) and needs no kernel changes. This is > what i suggested to Robert before and i've seen no argument why this > cannot be done. > > An added bonus is that the legacy oprofile kernel ABI can stay > completely untouched. (and the oprofile tooling can fall back to it)
I am fine with this. The oprofile daemon could be ported to use the perfcounters i/f and existing oprofile tools that are not ported may fall back to the legacy oprofile kernel ABI.
> And yes, AFAIK oprofile user-space is pretty much the only > user-space app that relies on the oprofile ABI - at least in the OSS > space. Robert, is there perhaps some bin-only oprofile based tool > that you implied before? Which one is it?
I know of hardware platform vendors using oprofile for system testing, but I don't know exactly how their user-land looks like and whether the daemon is used. AMD's CodeAnalyst tool (OSS) uses oprofile with an own daemon.
> > > That said, the lack of architecture support for perf is definitely > > a blocker here... > > Note, here's the current (roughly calculated, possibly inaccurate) > platform support matrix between oprofile and perfcounters: > > + : hw support available > 0 : sw support available > - : no support > > oprofile perfcounters > alpha + - > arm + - > avr32 + - > blackfin - - > cris - - > frv - 0 > h8300 - - > ia64 + - > m32r - - > m68k - - > m68knommu - - > microblaze - - > mips + 0 > mn10300 - - > parisc - 0 > powerpc + + > s390 0 0 > sh + 0 > sparc 0 0-[pending] > x86 + + > xtensa - - > > Takeaway points: > > - out of 20 hardware architectures, 8 have oprofile hw-PMU > support, 2 have timer-fallback support, 11 are not supported at > all. > > - out of 20 hardware architectures, 2 have perfcounters hw-PMU > support, 6 have sw event support, 12 are not supported at all. > > The architectures with the biggest practical weight are: x86, > powerpc, arm, mips. > > So there's a gap but it's not "all architectures" and the transition > to perfcounters is well underway. Still, oprofile obviously leads > (it has a 10 years headway) - and it's needed as a compatibility > option during the migration and even if perf had equivalent support > it would _still_ be around for some time as a pure ABI compatibility > thing.
Surely the argument of unsupported architectures will not be valid for a long time as its number for PCL will probably decrease fast.
> > > 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. > > Correct. That's my main point.
I don't want to have duplicate implementations, I want to have multiple interfaces using the same in-kernel implementation. The code base developed and tested will be the same then.
In the end I don't see much disagreement at all.
-Robert
-- Advanced Micro Devices, Inc. Operating System Research Center email: robert.richter@amd.com
| |