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