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
