pcp
[Top] [All Lists]

Re: [pcp] [RFC PATCH 1/1] Adding a PMDA to collect memory bandwidth

To: Nathan Scott <nathans@xxxxxxxxxx>, deepthi@xxxxxxxxxxxxxxxxxx
Subject: Re: [pcp] [RFC PATCH 1/1] Adding a PMDA to collect memory bandwidth
From: Hemant Kumar <hemant@xxxxxxxxxxxxxxxxxx>
Date: Wed, 22 Jul 2015 14:44:09 +0530
Cc: Joseph White <jpwhite4@xxxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <826217255.998997.1437434534979.JavaMail.zimbra@xxxxxxxxxx>
References: <1436678109-30878-1-git-send-email-hemant@xxxxxxxxxxxxxxxxxx> <1436678109-30878-2-git-send-email-hemant@xxxxxxxxxxxxxxxxxx> <513905742.40875370.1437117101643.JavaMail.zimbra@xxxxxxxxxx> <55AC5AF3.2010703@xxxxxxxxxxxxxxxxxx> <826217255.998997.1437434534979.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Hi Nathan,

On 07/21/2015 04:52 AM, Nathan Scott wrote:
Hi guys,

----- Original Message -----
[...]
This will mean you could make use of the existing PMDA instead of using
hard-coded events (like in this snippet of your patch...)
Ok, one question here, don't we need to hard code a subset of counters
at some or the other place even if we use the existing PMDA? The point
is, if we want to aggregate a certain number of counters, we have to hard
code those counters to be compared against.

Or, are you suggesting to make some kind of change to the
perfevent.conf file itself which will mark the below counters with some
marker to suggest the agent that these counters will be used in a derived
metric ?
Yep, thats the idea.  No hard-coding, all representation through the config
file.

Makes sense. Thanks for the explanation.

Few questions below :

Just had a thought that might make this all a whole lot simpler - it may be
possible here to combine use of pmdaperfevent (for direct hw counter access)
and the existing pmdasummary (for the server-side derivation calculation).

For example, lets pretend those memory metrics you're interested in are now
exported via perfevent.conf as, say, "perfevent.hwcounters.MEM.value".  You
might be able to create a pmdasummary configuration file like

summary.bandwidth.count = sum_inst(perfevent.hwcounters.MEM.value) / hinv.nnode;
summary.bandwidth.max = hinv.memory.max_bandwidth;

Here, the above perfevent.hwcounters.MEM.value represents the consolidated
value (aggregated and multiplied with the scale) or a single counter's value?

And, this configuration file for pmdasummary shall have to be in the client side,
right?

If that works, the only code you'd need would be the pmdalinux code behind
the new hinv.memory.max_bandwidth metric.

I think Deepthi mentioned a desire to also do interval/rate-based calculations
on the server-side as well - pmdasummary is doing that here already.  Details
on the pmdasummary(1) man page, and IIRC there might be a chapter in the Users
and Administrators Guide about pmdasummary and its use of pmie(1) too.

Ok, will look into pmdasummary to see if it helps.

--
Thanks,
Hemant Kumar

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