On 06/17/2015 01:20 PM, Nathan Scott wrote:
>
>
> ----- 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.
>
Sure. Will also look into extending the existing perfevent.
Thanks a lot.
Regards,
Deepthi
> cheers.
>
> --
> Nathan
>
|