pcp
[Top] [All Lists]

Re: [pcp] New perfevent PMDA

To: William Cohen <wcohen@xxxxxxxxxx>, "pcp@xxxxxxxxxxx" <pcp@xxxxxxxxxxx>
Subject: Re: [pcp] New perfevent PMDA
From: "White, Joseph" <jpwhite4@xxxxxxxxxxx>
Date: Mon, 14 Jul 2014 16:48:46 +0000
Accept-language: en-US
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53BD6DB8.6020801@xxxxxxxxxx>
References: <CFD1D0CD.C138%jpwhite4@xxxxxxxxxxx> <53B1D222.8010601@xxxxxxxxxx> <CFD83839.C4E7%jpwhite4@xxxxxxxxxxx> <53BD6DB8.6020801@xxxxxxxxxx>
Thread-index: AQHPkWQ7+Of6murkTkSMtOpXHkooOZuKb4wAgADuvwCADOepAIAHnjeA
Thread-topic: [pcp] New perfevent PMDA
User-agent: Microsoft-MacOutlook/14.4.3.140616
Answers inline below

On 7/9/14, 12:28 PM, "William Cohen" <wcohen@xxxxxxxxxx> wrote:

>
>--8<----
   SNIP
  --8<----
>
>Hi Joe,
>
>Thanks for explaining the relationship between PCP and XDMoD.
>
>I was able to build the perfevent pmda on an arm machine.  In general it
>looks like
>GNUmake should have "-lm -lpthread" added. Something like:
>
>LLDLIBS = $(PCP_PMDALIB) -lpfm -lrt -lm -lpthread

Thanks, I'll add this to my version too.

>
>
>How does one install the perfevent pmda/tests and run the tests?  I
>did try to run it but the results looked pretty questionable,
>particularly when it gave a "result: PASS" on the arm machine.  Then
>again that might be due to the fakefs lying what kind of machine this
>is.  Given that the performance monitoring hardware is very processor
>implementation specific is there some way to make the unit testing
>more aware of what kind of machine it is really on?

The unit test harness is deliberately independent of the underlying
machine architecture as it is designed to confirm that the perfevent code
behaves as designed and interacts properly with external interfaces (ie
the libpfm4 API and the linux proc filesystem API). I'm encouraged that
the tests pass on the arm architecture, since this makes me less worried
that there is any x86 specific code lurking in the source.

At the moment, there doesn't exist an automated method to do component
testing. Currently is a manual process, where you would run the full
perfevent PMDA and check the logs and query it using the normal pcp tools.

>
>
>To add support for new processors one would make entries in
>perfevent.conf?

Yes, the procedure that I suggest is as follows:
1) Run the perfevent PMDA on your target arch
2) Check the contents of the perfevent log file
(/var/log/pcp/pmcd/perfevent.log). This should list all of the detected
PMUs and the available hardware counters.
3) Edit the perfevent.conf to add a section for the desired PMU and the
desired counters. The PMU and counter names should be identical to the the
names listed in the log file in step (2)
4) restart the pmda and check that the desired counters appear.

For example, in step (2) you might see log output of the form (note this
is all a guess, since I don't have access to an arm box):

Found PMU: xscale2 (ARM) identification 2 (XX events YY generic counters
ZZ fixed counters)
xscale2::foo
xscale2::bar



To add the foo and bar counters to the configuration you would add some
lines of the form:


[xscale2]
xscale2::foo
xscale2::bar

After the pmda is restarted, then it should try to load the foo and bar
events if it is run on a system that has an xscale2 PMU.



>
>
>The pmda.c mentions duty cycle and that it is possible to have
>multiplexing.  Is there any way to group related events together,
>particularly ones that are used to derive ratio?  For example have
>memory references and cache misses in the same group and have floating
>point operations in a separate group.
>

No the current version always puts each event in its own group. The
libpmf4 api does support programming counters in groups, so adding event
grouping to the pmda is quite doable.

>
>
>Should the following be removed in perfmanager.c:
>
>/* REMOVE */
>#include <string.h>
>/* REMOVE */

Yes. - its probably dead code left over from some debug printing.

>
>
>Shouldn't PERF_ALLOC_LOCKFILE in perfmanager.h be tied to the location
>that pcp is installed $(PMDADIR}//perflock rather than
>assuming /var/lib/pcp/pmdas/perfevent/perflock is the correct place?
>

Yes. The code should probably be updated to check the appropriate pcp
environment variable.
 
>
>
>-Will

<Prev in Thread] Current Thread [Next in Thread>