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/
