If I read the overflow code correctly, the mask of the registers that
overflowed is stored in set->reset_pmds before the overflow hander is
called. Then the overflow handler does all of the registers in a loop.
It then determines if there were any 64 bit counter overflows or if the
overflow was simple an overflow of the smaller HW counter register.
>From what I see so far, it seems like the Cell interrupt enable/overflow
reporting should work ok within the perfmon2 code structure.
Carl Love
On Mon, 2007-03-26 at 17:45 -0500, Kevin Corry wrote:
> Hi Stephane,
>
> On Mon March 26 2007 5:30 pm, Stephane Eranian wrote:
> > > > I think it should not be too much work to put the field with in the
> > > > description table. With a flag, high level perfmon can just skip
> > > > consulting this field and go with a default.
> > >
> > > Yeah, I had similar thoughts about how to support multiple counter sizes.
> > > It should be relatively easy to add a counter_size field to the pfm_pmd
> > > structure and consult that in the overflow handling code.
> >
> > Yes, that is one place where the mask is used. But it is also used
> > when we write and read PMD registers (counters). I don't know how this
> > works on Cell, but on x86, you needs to set the upper bits of a counter
> > for it to trigger the PMU interrupt on overflow. For that you also need
> > to apply the counter width mask. The mask may also be used to determine
> > which counter overflowed, unless Cell provides a bitmask for that already.
>
> Interesting, I didn't realize that. I had only worked with the Pentium4
> previously, and it has the counter-overflow bit and the interrupt-enable bit
> in the per-counter control reigsters (CCCRs).
>
> On Cell, there is one global pm_status control register that is used to
> enable
> interrupts for each counter and to determine which counters overflowed (along
> with some status bits related to the hardware sampling feature).
>
> Hmmm....now that I take another glance at the Cell PMU docs, I see that
> reading the pm_status register clears all the status bits and resets the
> pending interrupts. This means that the overflow handler may have to handle
> the overflow of multiple counters in one run (in addition to dealing with
> hardware-sampling interrupts). I haven't gone through Perfmon2's overflow
> interrupt handling enough to know if this will cause any problems. Any
> thoughts?
>
> Thanks,
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
