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.
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;
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.
cheers.
--
Nathan
|