On Fri, 2008-06-13 at 10:01 -0400, Dan Terpstra wrote: > So... > Does this have to happen at kernel level or at libpfm level? > I'm assuming at this point that it *shouldn't* happen at PAPI level :) > In other words, is this in Carl's domain or Yoshio's? > And can we do this for 32-bit counters without negatively impacting 16/32 > support? > - d >
The virtual 64 bit counter stuff is done in the generic perfmon2 kernel code. The architecture perfmon2 code just has to have the right calls to support it. The CELL perfmon2 architecture support for virtual 64 bit counters is all the architecture specific perfmon2 code. As mentioned the 64 bit virtual support all works with the CPC performance counter tool for CELL which is built directly on top of Perfmon2 since CPC sets the interrupt bits. At this point all we should have to do is to fix the default values for the counters and it will just work. > > > -----Original Message----- > > From: stephane eranian [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 12, 2008 6:48 PM > > To: Carl Love > > Cc: Dan Terpstra; perfmon2-devel@lists.sourceforge.net > > Subject: Re: [perfmon2] CYCLES overflow on perfmon2 on Cell > > > > Carl, > > > > On Thu, Jun 12, 2008 at 11:39 PM, Carl Love <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, 2008-06-12 at 17:00 -0400, Dan Terpstra wrote: > > >> Are counters virtualized on overflow? I thought they were virtualized > > by > > >> accumulating at context switch. Or maybe that was just perfctr. Seems > > to me > > >> this would imply that *all* counters would need interrupt on overflow > > >> enabled *all* the time. > > > > > > The 64 bit virtual counters get updated on a hardware counter overflow. > > > Hence if you do not enable HW interrupts no 64bit accumulation occurs, > > > i.e. 32 bit counter with wrap around. So yes, they need to be enabled > > > all the time. What Stephane is saying is we need to make sure perfmon2 > > > sets the bits by default by setting up the default value to write to the > > > register to have these bits set. > > > > > > Here is how we defined the pm_status register for cell > > > (arch/powerpc/perfmon/perfmon_cell.c): > > > > > > PMC_D(PFM_REG_I, "pm_status", 0, 0, 0, 0), > > > > > > The PMC_D is a macro that assigns the various fields to the structure > > > fields. The first 0 is the defalut power on value, the second 0 is the > > > reserved mask, the third is the no 64bit emulation mask, the last 0 is > > > the hardware address. Given this definition, the user level tool (PAPI > > > or CPC) must make sure the interrupt enable bits get set. > > > > > > >From what Stephane is saying, it sounds like we need to change the > > first > > > 0 to 0xF000 0000 to have perfmon2 always enable the interrupts on the > > > four 32bit counters. We will have to think about this a lot more if we > > > try to support 16 and 32 bit counters. You do not want to use a 16bit > > > counter to count cycles or instructions. The overhead of the interrupt > > > processing will kill you. The second 0 should be 0xF000 0000 as well to > > > set the reserved mask to prevent the users from clearing the interrupt > > > enable bits. It should be: > > > > > > PMC_D(PFM_REG_I, "pm_status", 0xF0000000, 0xF0000000, 0, 0), > > > > > > Do I have this correct Stephane? I have tested it yet, I am just > > > winging it! :-) > > > > > > > If bit 31 is your interrupt enable, then yes you have it correct. With > > this interrupt > > will always be enabled no matter what value the user sets. > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
