Hi, On Tue, May 09, 2006 at 10:53:04AM -0500, Kevin Corry wrote: > > Do you know what "extended" means? Are they just adding more events, or are > they adding more counters and/or control registers? Is that documented > anywhere? > > The IA-32 Intel Architecture Software Developer's Manual > (http://www.intel.com/design/Pentium4/manuals/253669.htm) describes the > details the various PMUs. But it only refers to the high-level families like > P6, Pentium-M, and Pentium4/Xeon. It doesn't make distinctions for the > different cores that are available within the various families. If they > actually do make significant changes in the PMU between different cores in > the Pentium4 line, it's going to make supporting them in perfmon quite a > chore. > On the Intel side, my understanding is that we have: - family 15 : P4 PMU model (CCCR/ESCR style) - family 6 : P6-style (PERFEVNTSEL/PERFCTR style)
I would like someone to tell us whether within those 2 families there are models which do not have a PMU or have a different PMU style. Today the code is fairly cautious in that it only allows models which we have tested to work. But I do not have access to all existing models nor do I know where to find this information nicely summarized in a table. Maybe we need to decryupt the Oprofile or perfctr code to find this out. Now, something really interesting introduced with the latest version of the IA-32 architecture manual in volume 3B (chapter 18) is the notion of an architected PMU. This PMU uses the PERFEVNTSEL/PERFCTR style. It comes with architected events as well. There is also provision via CPUID to query if architected PMU is supported and some of its characteristics. This looks good and getting closer to the nice Itanium PMU architecture. Unlike Itanium, though, it seems that the architected PMU is not required for every implementations (understood it is not there on existing models). This architected PMU + mode-specific extensions is implemented starting in Core Duo/Solo processors. Those are part of family 6. Why is an architected PMU interesting for perfmon? Because it makes it possible to possible to have a generic PMU description table and libpfm support. If you have the model specific support then use it, otherwise default to the generic (architected) support. This is what we do on Itanium today. With this approach new hardware can be supported faster and applications can be guaranteed a minimum level of functionalities by the PMU. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
