On 06/24/2014 10:43 PM, Lukas Berk wrote:
> Hey,
>
> As Nathan noted on the PCP developer conference call agenda[1], I've been
> working on a new pmda for accessing Performance API counters. The
> latest iteration has been pushed to the lberk/papi branch on pcpfans[2]
> for anybody that would like to take a look (I would greatly appreciate
> any feedback). Some potential points of interest (and maybe things to
> discuss on tomorrows call?):
>
> - I've decided to experiment with adding the metrics of interest on a
> per client basis, instead of a global-enabled-all-metrics variable
> which is set with the pmstore functions. I think this approach might
> be worth applying here so we're more surgical in which events are
> actually included in the active papi 'eventset', hopefully lowering
> our performance hit while papi functionality is enabled.
>
> - Currently just system wide events are reported, but I'd like to add
> functionality for a per-process domain
>
> - I'm aware that what is currently in the branch assumes papi is
> installed on the machine running the PMDA. I'll be adding the
> required configury bits moving forward to check for papi first.
>
> - Currently the PMNS is fixed, a possible stretch goal would be to
> dynamically create the PMNS based on what papi events are actually
> available on the specific hardware.
>
> - I've structured the PMNS currently to resemble
> papi.kernel.<metric_name>
> where 'metric_name' is similar to the papi 'event code' (ex,
> total_inst or L2_TCM). This approach would leave room for the process
> name once the per-process domain is added.
>
> - Only root level UID's are allowed to access the papi values
>
>
> Looking forward to discussing this tomorrow on the call, and any
> thoughts on list welcome as well.
>
> Thanks,
>
> Lukas
>
> [1] -
> http://www.performancecopilot.org/pipermail/pcp-announce/2014-June/000043.html
> [2] -
> https://www.sourceware.org/git/gitweb.cgi?p=pcpfans.git;a=shotlog;h=refs/heads/lberk/papi
>
>
>
> _______________________________________________
> pcp mailing list
> pcp@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/pcp
>
Hi Lukas,
I am looking over the papi pmda code and I have the following
questions and comments.
The following is more of an desired future feature that requires
changes to current papi. It would be really nice if this (and other
pmdas) allowed grouping by cgroups. This would be really useful for
things using containers such as docker and openshift. Then it would
make it easy to pick out problem containers.
Some processors do not implement all versions of
pap.kernel.L[123].[IDT]CM listed in metrictab imlemented. Do these
fail gracefully in the papi pmda?
Is it expected when trying my locally built pcp RPM with papi patches
I needed to manually do the following or is something missing for the
install?
cd /var/lib/pcp/pmdas/papi
sudo ./Install
"pminfo -FT papi" only appears to work as root? Shouldn't there be a
note on that? Or would it be possible to pminfo just check to see that
the event is available within a process and extrapolate that it should
be aavailable system-wide? Also got messages like the following for
virtually all of the events (there isn't anything else using the pmu
at the moment):
papi.kernel.L1_STM
Help:
Level 1 store misses.
Error: Try again. Information not currently available
In papi_fetchCallBack() the switch statement codes the magic numbers
to various entries. Isn't there a more compact and regular way to
code that? Would it be possible to use negative number for control
and have the events be positive to avoid having to offset some values by 1?
-Will
|