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

[Stephane Eranian <eranian@hpl.hp.com>]

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.
> 

-- 

-Stephane