Please see pcpfans.git fche/papi for a possible solution to the first
problem Nathan's coverity note.
commit d87918b71cd9d0b0a327325c80bf54105c7027e9
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Tue Feb 24 19:49:21 2015 -0500
papi pmda: improve papi auto-enable & batching, related error handling
A coverity report [1] indicated problems in the way errors from a
sequence of operations were being (not) propagated out properly.
Defining what's proper is not easy, because when reading N counter
metrics, especially in auto-enable mode, may involve partial
failures. The recently added refresh-batching logic made this aspect
of the situation more confusing.
In the partial failure scenario, some counters give values, others
lack them (never having been activated), yet others fail (an
activation having been rejected). Now, per-counter fetch status is
separated into those categories at papi_fetchCallBack time: success,
vs. PMDA_FETCH_NOVALUES vs. PM_ERR_VALUE.
This is accomplished by always batching a single refresh_counter() at
the beginning of a papi_fetch(), so that by the time the individual
counters are fetched, we know whether they were requested or not, and
whether those requests succeeded. This also allows first-time fetches
of auto-enabled counters to carry proper initial values (so no more
"no values ..." initial warnings from a pmval over an auto-enabled
papi counter). The papi.control.batch metric is no longer used and so
eliminated.
[1] http://oss.sgi.com/archives/pcp/2015-02/msg00081.html
|