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