Hey,
Nathan Scott <nathans@xxxxxxxxxx> writes:
>> sudo pmstore papi.control.enable "L1_TCM L1_TCH" (enable/disable being a
>> space or ',' sperated list)
>> sudo pmval papi.T1_TCH (view subsequent output)
>> sudo pmval papi.T1_TCM (view more output)
>> sudo pmstore papi.control.disable "L1_TCM,L1_TCH"
>
> Often this'd be documented in the man pages (see pmdagluster(1), or
> pmdagfs2(1) for an example of their control metrics use - possibly a
> bit of boilerplate doc could be lifted from those?) or in the README
> file for a PMDA if it has one (see the pmdashping(1) control file
> metric discussion in its README) - nothing major, just a quick demo
> doc like you've done here that can live in the git tree & installed
> files.
Good point, I've updated the pmdapapi man page to include this example
and output.
>> A few other TODO's I have lined up for the pmda: I'd like to eventually
>> make the enable/disable control metrics a bit more flexible (ie, pmstore
>> papi.control.disable "*" or "all" would be nice). We're also working
>
> I like it, I think those would be neat extensions. Franks suggestion
> (I think it was Franks? sorry, seems like I've been on a different
> planet for a week) of a more general regex model (e.g. "L1*") is also
> a good one IMO - that would then cover matching on "*" and is unlikely
> to conflict with the PAPI metric names I'd guess.
Sure, I've made note of it.
>> papi.control.{enable,disable} metrics. (and of course, more qa as
>> needed)
>
> Yes please. :) So, we ran out of time for valgrind checking, that
> would be a delight to see (as discussed end of last release) and we
> had chatted about improving that initial coverage of pmstore error
> handling - I'd love to see more in that area if you have time (the
> little I did there didn't really attack the harder problems - like
> enabling hardware counters which are incompatible with each other,
> such that PAPI errors out when they're enabled together - that kind
> of thing). Tricky cases like that are an area of on-going, wider
> interest, so a reproducible test case of known-whacky PAPI/hardware
> scenarios would be most excellent to have up our sleeves.
All noted and on my TODO. I'll start looking into the conflicting
cases as well!
> Thanks Lukas! Also, you mentioned earlier today those per-process
> metrics were proceeding nicely, and that the next update was around
> the corner - please include in that one the spec file fix to switch
> this on by default for Fedora builds, and a back-port of the s390(x)
> fixes - these'll live in build/rpm/fedora.spec for the next release.
I've backported the fixes (in lberk/papi currently), and I'll send
another pcp updates email when I have per-process metrics up and running
as well.
Thanks for the comments,
Lukas
|