Kevin, On Mon, May 08, 2006 at 10:11:29AM -0500, Kevin Corry wrote: > On Mon May 8 2006 2:39 am, Stephane Eranian wrote: > > > perfmon2 doesn't work on Sossamans because it doesn't know about the cpu > > > model Sossaman is model 14. > > > I copied the "case" statements for model 13 which is supposed to be > > > Pentium-M and it seems to work. > > > > Careful here, I don't know all the various Pentium models are their PMUs. > > There is only support for Pentium M style PMU in libpfm and pfmon. > > As well as support for P6 (Pentium Pro/II/III), which is just a simpler > version of the Pentium-M. > > > If you > > know for sure that your PMU model is like Pentium M, then it is safe to > > enabel support in libpfm and pfmon. Otherwise you may get garbage. > > > > > The Dempsey (family 15, model 6) is also not handled properly, but I > > > couldn't check whether a simple copy of model 5 would work. > > > > Do you have an Intel document that clearly describes the various models and > > their PMU support. I would expect more models to follow the Pentium 4/Xeon > > PMU rather than the Pentium M PMU. > > Based on some searches on Intel's website, it looks like Sossaman is based on > the mobile architecture (meaning Pentium-M), but Dempsey looks to be a > Pentium-4/Xeon/EM64T derivative, which means its PMU is vastly different. >
I don't think I have a Sossaman nor a Dempsey CPU. Could someone just verify that this statement from Kevin is correct and provide a patch to libpfm to add support for those processors? > And since we're on the subject, I've been slowly working on Pentium-4 support > for libpfm. However, in order to properly support Pentium-4, I think we're > going to need to add the concept of event-masks (or unit-masks as I think > they're called in oprofile). If my calculations are correct, counting each > allowable mask combination on Pentium-4 may lead to more than 72,000 total > events, which libpfm obviously isn't going to be able to handle with a flat > array of events. > Yes, I think we had that discussion a while back w.r.t to Power5 and P4. I also made another change very recently to accomodate a behavior specific to MIPS where the value of an event differs based on which counter it is programmed into. I agree with you that the libpfm interface has to be extended somehow to cut down on the number of events and use a more hierarchical approach. > Right now libpfm has the pfm_find_event_* and pfm_get_event_* APIs. My > initial > impression is that we could add APIs along the lines of pfm_find_event_mask_* > and pfm_get_event_mask_*, which would search within one specified "parent" > event for the specified mask information. And pfm_dispatch_events() and its > input parameters would have to be updated to account for these event-masks. > And obviously if a PMU doesn't have the notion of event-masks (like > POWER4/5), then it simply doesn't need to provide any information for these > new APIs. Any thoughts? > If I understand correctly, you are suggesting a 2-level approach where you search for the main event first, using the handle you get back, you then search for a unit mask. On processors without unit mask or where a flat list of events is manageable the second call would just return nothing. That looks like a reasonable approach because it provides backward compatibility with existing code. We could also provide a new function that would combine the two together for new programs. > I haven't written anything concrete yet for these ideas, but I'm getting > there > now that I've got a better handle on the Pentium-4 PMU details. I'll send in > some patches once I have something worth showing. > Excellent. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
