Dan, You should not have to worry about settings the register bit to enable 64-bit virtualization. You can leave zero there.
On Fri, Jun 13, 2008 at 4:49 PM, Carl Love <[EMAIL PROTECTED]> wrote: > > 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
