Hi,

In the last couple of weeks, I have made several important changes and
bug fixes. I'd like to share them with you and explain the key ones.

An important change is that I wanted users to be able to list events and
encodings for PMUs that are not detected on the host system. This is
important for validation purposes. I did not want to have to be on the target
system to validate a specific PMU model. I wanted some more practical than
forcing PMU models via environment variables.

To fullfil this goal, I have changed the logic inside the generic code
w.r.t. to how
event strings are parsed. If an event string does not have an explicit PMU name
prefix, e.g., inst_retired:any_p, then the library only looks among
the detected PMUs.
If the PMU prefix is present, e.g., core::inst_retired:any_p, then the
library only looks
in the corresponding table, regardless of whether the PMU is present or not.

A side effect of this change is that pfm_get_event_first() and
pfm_get_event_next()
now return the list of all  available events. Here 'available' means
'compiled into' the
library. From the list, it is possible to figure out whether an event
is actually
supported by the host HW using the get_pmu_info() on the event's pmu identifier.

Another change is that I wanted the ability to list all events in each
table. I really
mean ALL. Some event tables, e.g., AMD64, have events that are only active
when certain processors or stepping are detected. While this save on duplication
of events, it makes it harder to access certain events. That means
they cannot easily
be listed. To fix this, I will soon post a patch that will break this
into separate PMU
models. They will still all share the same event table, but each PMU
variation, e.g.,
AMD Barcelona vs. Shanghai vs. Istanbul, will all be explicitly exposed to the
user. Using their PMU names, it will be possible to list and validate
the encodings
that are specific to Barcelona without being on a Barcelona processor.

Overall, I think this is cleaner. There are a couple more Intel PMUs which have
this problem. I will clean those up as well.

Here is the output of showevtinfo to make things more explicit. This
was captured
on a Westmere Core i5:

Supported PMU models:
        [6, p6, "Intel P6 Processor Family"]
        [8, coreduo, "Intel Core Duo/Core Solo"]
        [9, pm, "Intel Pentium M"]
        [10, core, "Intel Core"]
        [11, ppro, "Intel Pentium Pro"]
        [12, pii, "Intel Pentium II"]
        [13, atom, "Intel Atom"]
        [14, nhm, "Intel Nehalem"]
        [15, nhm_unc, "Intel Nehalem uncore"]
        [16, ix86arch, "Intel X86 architectural PMU"]
        [51, wsm_unc, "Intel Westmere uncore"]
        [52, wsm, "Intel Westmere"]
        [54, amd64_k7, "AMD64 K7"]
        [55, amd64_k8_revb, "AMD64 K8 RevB"]
        [56, amd64_k8_revc, "AMD64 K8 RevC"]
        [57, amd64_k8_revd, "AMD64 K8 RevD"]
        [58, amd64_k8_reve, "AMD64 K8 RevE"]
        [59, amd64_k8_revf, "AMD64 K8 RevF"]
        [60, amd64_k8_revg, "AMD64 K8 RevG"]
        [61, amd64_fam10h_barcelona, "AMD64 Fam10h Barcelona"]
        [62, amd64_fam10h_shanghai, "AMD64 Fam10h Shanghai"]
        [63, amd64_fam10h_istanbul, "AMD64 Fam10h Istanbul"]
Detected PMU models:
        [16, ix86arch, "Intel X86 architectural PMU", 6 events]
        [51, wsm_unc, "Intel Westmere uncore", 52 events]
        [53, wsm, "Intel Westmere", 89 events]

$ showevtinfo -E amd64_k8_revf::cpu_clk_unhalted
0x530076        amd64_k8_revf::CPU_CLK_UNHALTED


Among the many other changes:

- updated Intel Westmere event tables (based on PTU). More updates to
  come.

- fixed several important bugs in the generic code

- added event table validation to AMD64, perf PMU

- vastly improved showevtinfo with more encoding, and umask listing
  options. Check out showevtinfo -E, showevtinfo -L. Add -M to list
  all combinations (careful, this can be very slow due to combinatorial
  explosion on some PMU models, e.g., perf::).


I have not yet released version 1.0 of libpfm4, therefore, the API/ABI may
still fluctuate as I make some more minor improvements.

Stay tuned...

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to