pcp
[Top] [All Lists]

Re: [pcp] PCP papi PMDA

To: Lukas Berk <lberk@xxxxxxxxxx>, William Cohen <wcohen@xxxxxxxxxx>
Subject: Re: [pcp] PCP papi PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 3 Jul 2014 00:56:44 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20140702135330.GD12723@xxxxxxxxxx>
References: <20140625024307.GA9275@xxxxxxxxxx> <53B1AF59.9080506@xxxxxxxxxx> <20140702135330.GD12723@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: y9ZRMHVNawuRbDPJ/4sJ4JbIV0vhjA==
Thread-topic: PCP papi PMDA
Hi guys,

----- Original Message -----
> > [...]
> > 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?
> 
> Looking at that portion of the code, you're absolutely correct.  After
> refactoring out the PAPI_add_event code, there's no real reason to have
> the switch statement in the fetchcallback.  FWIW the 'offset by 1' is an
> artifact of the enable_counters variable (used in the pmstore enabling
> counters approach).  I'll reorganize the pmns and fetchcallback function
> as needed.

BTW, a good approach to use here is to have separate PMID "clusters"
for separate conceptual things.  Then you can arrange the PMID "item"
field as an index (if that helps), and use "cluster" to disambiguate
from unrelated things (control metrics, preset vs native, and so on).

cheers.

--
Nathan

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