----- Original Message -----
> Hi Nathan,
>
> On 06/17/2015 07:24 AM, Nathan Scott wrote:
> > Hi Deepthi,
> >
> > ----- Original Message -----
> >> Hi all,
> >>
> >> I am relatively a new user exploring PcP.
> >> My use case being, invoking already supported PcP monitors like
> >> 'pmval' directly from an application.
> >>
> >> I am aware of API bindings that PcP exposes. These are to connect
> >> to the daemon pmcd and get the values of counters directly but
> >> this does not involve any post processing of data. As far as I
> >> understand post processing is done as part of monitors.
> >>
> >> Are there monitor APIs that can be invoked from an application ?
> >>
> >
> > It sounds like the pmRegisterDerived(3) API might suit here. Also
> > see the 'ENVIRONMENT' section of the PCPIntro(1) man page where it
> > describes the PCP_DERIVED_CONFIG env variable - this may allow you
> > to use derived metrics in your application without modifications.
> >
>
> Thank you very much for the pointers. I did give it a try but
> unfortunately it does not seem to fit into my workflow.
>
> Scenario is:
>
> I am trying to compute memory bandwidth of a system. This can be
> achieved by reading a bunch of PMU counters via perfevent, Aggregating
> those values, Multiplying with a scale as mentioned in the sysfs entry
> on the system and some more math on top of it to get a single metric
> value denoting the memory bandwidth of the system.
>
> Also, to note is that PMU counter names will vary depending on the
> architecture. Ideally I would want to consume this metric via OpenStack.
> Given this scenario, OpenStack will be my client. Ideally I need to have
> all the reading of counters and math on top of it there.
>
> From an OpenStack consume-ability side, it should connect to the pmcd
> daemonand get the required single aggregated post processed metric in a
> single call irrespective of underneath architecture.
>
> So where do we do all the required post processing and required math
> here ? :-(
>
> Given the requirement, would it be good to have all
> the architecture dependent stuff i.e reading PMUs and related math in
> PcP and just return the memory bandwidth metric to OpenStack ?
>
> This would result in a cleaner design where all the architecture
> dependent counters and computation is done in the backend PcP and just
> the value is returned to OpenStack.
>
> Again in PcP, as we will not be able to use pmRegisterDerived(), would
> it be better to write a new PMDA that would essential read all the
> required counters and do the math based on the underlying architecture ?
>
Yep, sounds like a good approach to meet those requirements. You might be
able to extend the existing pmdaperfevent(1) agents configuration language
to represent the kinds of derivations you're looking for here, rather than
starting from scratch with an entirely new agent? Man perfevent.conf(5) &
src/pmdas/perfevent in the PCP git tree for details.
cheers.
--
Nathan
|