> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@xxxxxxxxxx]
> Sent: Saturday, 7 March 2015 7:27 AM
> ...
> It's a bit tricky to read PAPI history, to see at what point support for
any
> particular cpu family & model were added. I can't quite pick out whether
your
> modernish Opteron is or isn't supported by papi per se, and whether your
> kernel lets it work (both may be necessary).
I am sure the h/w supports this ... the tests run and pass on the native
machine running a Debian derivative. This would seem to support that
hypothesis ...
kenj@bozo:~$ papi_avail | grep TOT_INS
PAPI_TOT_INS 0x80000032 Yes No Instructions completed
> The clincher is:
>
> > kenj@vm14:~$ papi_avail | grep TOT_INS
> > PAPI_TOT_INS 0x80000032 No No Instructions completed
>
> Methinks 813 should _notrun if that third column is "No". (Arguably, the
papi
> pmda should have filtered out that from the listed metrics in the dynamid
pmns
> too.)
Since this involves several tests, seems like the _pmu_present() function
should be factored out of all of these tests an put in common.check (or
somewhere similar) and then generalized to accommodate the restriction
you've suggested. The only issue here is that papi_avail is not installed
by default, so we introduce yet another package dependency for QA and I
can't even find a package containing papi_avail for a standard Debian
distro.
I'll await your thoughts before doing anything more on this one.
|