Stephane -
I tested this on an opteron rev C patched with perfmon, and an opteron model
33, stepping 2 (Rev E?) patched with perfctr and running a hybrid
libpfm/perfctr version of PAPI. I did white box testing only (does it still
work?) and things look ok. I enumerated across all possible native event
variations and things look ok. I didn't specifically try to count any
invalid events.
This testing did point out a couple problems in PAPI: our model decode for
opteron is out of date, and our strings aren't long enough for the worst
case event name (CPU_IO_REQUESTS_TO_MEMORY_IO with all 10 mask bits!). So I
guess it was worthwhile...
- dan

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:perfmon-
> [EMAIL PROTECTED] On Behalf Of Dan Terpstra
> Sent: Wednesday, June 06, 2007 9:20 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [perfmon] AMD events and revisions
> 
> I'll try it out and let you know.
> - dan
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:perfmon-
> > [EMAIL PROTECTED] On Behalf Of Stephane Eranian
> > Sent: Tuesday, June 05, 2007 4:12 PM
> > To: Dan Terpstra
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [perfmon] AMD events and revisions
> >
> > Dan,
> >
> > I have just pushed into CVS a modified event table for AMD64 along
> > with the corresponding CPU revision checking in the
> pfm_dispatch_events()
> > code.
> >
> > I used the single table approach with a new set of 'revision' flags.
> > I tested this on my (old) rev C machine and it seems to work well.
> >
> > Let me know if it works with your Opteron machines.
> >
> >
> > On Thu, May 10, 2007 at 10:02:43AM -0400, Dan Terpstra wrote:
> > > Having the ability to discriminate based on revision would be a *good
> > > thing*. I'm not particularly fond of the mix-n-match approach taken
> for
> > > PIII. Although I understand why it's necessary. Is there not some way
> to
> > > implement a more generic solution through the flags field? I.E. Rev E
> > maps
> > > to flag bit 6. If that bit is set and you aren't Rev E, return error.
> > > That may change some calling semantics, tho...
> > > - dan
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED] [mailto:perfmon-
> > > > [EMAIL PROTECTED] On Behalf Of Stephane Eranian
> > > > Sent: Wednesday, May 09, 2007 4:52 PM
> > > > To: Dan Terpstra
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: [perfmon] AMD events and revisions
> > > >
> > > > Dan,
> > > >
> > > > Here is another thought on the AMD event table.
> > > >
> > > > It seems that several events are marked with a processor
> > > > revision, e.g., rev E. The table does not yet capture this
> > > > kind of restrictions. I think it would be worth adding
> > > > support for Revision checking to avoid mistakes.
> > > >
> > > > The libpfm API does not support event tables with holes in
> > > > the indexing. As such we would have to provide multiple tables
> > > > based on the revision. Note that they could be built from
> > > > macros stitched together like what I did for Pentium II vs. Pentium
> M.
> > > >
> > > > Then in the detect() routine, we would initialize the current table
> > > > pointer just like what we do for PIII.
> > > >
> > > > Now I don't know the mapping between the Revision letters and the
> > > > family/model numbers but I am sure we could find this out.
> > > >
> > > > What do you think?
> > > >
> > > > --
> > > > -Stephane
> > > > _______________________________________________
> > > > perfmon mailing list
> > > > [email protected]
> > > > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
> >
> > --
> >
> > -Stephane
> > _______________________________________________
> > perfmon mailing list
> > [email protected]
> > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
> 
> _______________________________________________
> perfmon mailing list
> [email protected]
> http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/

_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/

Reply via email to