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
