Re: [perfmon] Re: 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K support + libpfm available

[Philip Mucci <mucci@cs.utk.edu>]

Stefane,

Are you saying that oprofile user level tools don't even use the
oprofile driver but rather just set up a system-wide IP-sampling context
for perfmon2?

Think of all the work that Ralf just did. ;-)

Phil

On Thu, 2006-01-19 at 10:16 -0800, Stephane Eranian wrote:
> Ralf,
> 
> On Thu, Jan 19, 2006 at 01:36:09PM +0000, Ralf Baechle wrote:
> > > PAPI is also in the works for these systems. Feel free to give it a spin
> > > and tell us where it breaks or otherwise offends you. 
> > > 
> > > P.S. The code should be relatively easy to extend to other members of
> > > the product line...currently I've only got kernel code in for
> > > 5K/20K/25K, which are nearly identical as far as the PMC goes. 
> > 
> > More recently myself and others have verified that Oprofile is working
> > on the 5K, 20K, 24K, 25K cores and the SB1 and SB1A cores in the Sibyte
> > SOCs - and a few more in the queue.  So now I wonder how perfmon2 is
> > going to interfear with oprofile which already is in the kernel?
> > 
> On Itaniun, where perfmon was orginally designed, we have Oprofile and
> perfmon2 working together. You can use Oprofile or perfmon2 native tools.
> 
> Oprofile user level tools are using the perfmon2 interface to program the
> counters. But the sampling buffer format and buffer export interface remain
> the same as with "native" Oprofile. As Phil mentioned, perfmon2 implements
> a kernel evel sampling buffer. But the format of the buffer, i.e., what gets
> recorded, how it is recorded in the buffer and how the buffer gets exported
> to user is implemented by a simple kernel module called a "custom sampling
> format". The core of each format is a handler function called on counter
> overflow. We use this mechanism to connect the Oprofile PMU interrupt handler
> to perfmon, it is just 100 lines of C and we reuse the full Oprofile sample
> recording infrastructure.
> 
> There is nothing specific to Itanium is thr way Oprofile is connecte to perfmon2.
> As such, I believe that we could implement the same trick on all the other
> architectures supported by perfmon2. I think some people would like to try this
> on i386 first. But you are certainly welcome to try this on MIPS. The Oprofile
> tools are already aware of perfmon on Itanium. It may be that they need to be
> made ware when compiling for i386 or MIPS.
> 
> The goal of perfmon2 is not to get rid of OProfile but to allow the two
> to work side by side but avoid duplication of kernel code as much as possible.
> Some people are satisfied with the functionalities of Oprofile others are not,
> especially because Oprofile does not provide per-thread monitoring. The perfmon2
> interface is designed to be generic and flexible, it was designed with a particular
> tool or measurement in mind.
> 
> > I've put a quick page into the wiki at http://www.linux-mips.org/wiki/Perfmon2
> > It's really just a starting point but people should know what's there.
> > 
>