[Top] [All Lists]

Re: [perfmon] Re: 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K supp

Subject: Re: [perfmon] Re: 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K support + libpfm available
From: Philip Mucci <>
Date: Thu, 19 Jan 2006 19:38:56 +0100
Cc: Ralf Baechle <>,,
In-reply-to: <>
Organization: Innovative Computing Laboratory
Original-recipient: rfc822;
References: <1137666602.6648.80.camel@localhost.localdomain> <> <>

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


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 
> >
> > It's really just a starting point but people should know what's there.
> > 

<Prev in Thread] Current Thread [Next in Thread>