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!  :-)

              Carl Love
> - d
> 
> > -----Original Message-----
> > From: Carl Love [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 12, 2008 4:41 PM
> > To: [EMAIL PROTECTED]
> > Cc: Dan Terpstra; perfmon2-devel@lists.sourceforge.net
> > Subject: Re: [perfmon2] CYCLES overflow on perfmon2 on Cell
> > 
> > Yes, I was actually referring to the HW configuration being disabled by
> > default.  I will take a look to see if we did anything in the perfmon2
> > code to force it on.  I don't remember the code is setup to force the
> > overflow bit to be set in the HW register.   I will need to double check
> > the code as there were two of us working on the code.  But from the
> > sounds, it probably wasn't done and we will need to fix that.
> > 
> >               Carl Love
> > 
> > On Thu, 2008-06-12 at 22:30 +0200, stephane eranian wrote:
> > > Carl,
> > >
> > > I know that typically interrupt generation on overflow is turned off by
> > default.
> > > What I am saying is that you should force it in software on setting the
> > bits in
> > > the default value of the register and protecting them from the user
> > using
> > > the reserved mask. Perfmon guarantees 64-bit counters by default.
> > Virtualization
> > > is achieved  via the interrupt overflow, thus it needs to be enabled by
> > default.
> > >
> > >
> > > On Thu, Jun 12, 2008 at 10:24 PM, Carl Love <[EMAIL PROTECTED]> wrote:
> > > > I will have to take a look and see what was done.  Off the top of my
> > > > head, I don't remember.  Interrupt generation can be enabled/disabled
> > > > for each counter.  By default they are disabled.
> > > >
> > > >            Carl Love
> > > >
> > > > On Thu, 2008-06-12 at 22:19 +0200, stephane eranian wrote:
> > > >> Carl,
> > > >>
> > > >> If you need to set a bit to generate interrupt on overflow, like most
> > > >> other processors,
> > > >> then I suggest you leverage the default value/reserved bitmask fields
> > of the PMU
> > > >> register description table to enforce that the bit is set no matter
> > > >> what. We use this
> > > >> approach on Itanium and X86. That will avoid problems. Of this is
> > > >> unless, there is
> > > >> a valid use for turning that bit off. Note that we do also support
> > > >> this on Intel X86
> > > >> processors when using PEBS.
> > > >>
> > > >>
> > > >> On Thu, Jun 12, 2008 at 10:00 PM, Carl Love <[EMAIL PROTECTED]> wrote:
> > > >> >
> > > >> > On Thu, 2008-06-12 at 15:40 -0400, Dan Terpstra wrote:
> > > >> >> Hi -
> > > >> >> In preliminary testing of PAPI on perfmon2/Cell, it appears that
> > the CYCLES
> > > >> >> event produced by pfm_get_cycle_event() is not virtualized beyond
> > 32 bits.
> > > >> >> One of the basic PAPI tests shows this quite clearly:
> > > >> >
> > > >> > Virtual 64 bit counters on CELL do work.  The virtual counters work
> > for
> > > >> > the CPC tool which works directly on the perfmon2 API.
> > > >> >
> > > >> > Please make sure that the CELL pm_status register is configured to
> > > >> > enable interrupts on counter overflow for the counter you are
> > using.
> > > >> > Bits 0:7 of the 32 bit register where (0 is the MSB and 31 is the
> > LSB)
> > > >> > correspond to the 8 16 bit counters.  For CELL, we only support 32
> > bits
> > > >> > which means you need to set bits 0:3 in the register for counters 0
> > to
> > > >> > 3.
> > > >> >
> > > >> > <snip>
> > > >> >> Is this (not) happening in the kernel or in the libpfm layer?
> > > >> >> Does the same apply to other events as well?
> > > >> >>
> > > >> >> - d
> > > >> >>
> > > >> >
> > > >> > This will be true for all events.
> > > >> >
> > > >> >                  Carl Love
> > > >> >
> > > >> >
> > > >> >
> > > >> > -------------------------------------------------------------------
> > ------
> > > >> > 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
> > > >> >
> > > >
> > > >
> 


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

Reply via email to