Apologies for the tardy reply, mayhem this week.
----- Original Message -----
> [...]
> Yes, except that pmval is limited to a single metric per invocation.
> A single "pminfo cgroup" run can exercise all metrics, and "pminfo
> cgroup cgroup cgroup ..." can endurance-test all metrics, not just the
> one that we found/fixed this leak in, so it's more forward-looking.
This is trivially tackled as in test qa/957 and results in a better
test - that one even points out which cluster the pmdalinux bugs it
finds are in (done that way on purpose, to save diagnosis time)!
For bonus points, we get valgrind testing on pmval which is missing
currently (may have overlooked the earlier review comment seeking
updates to qa/731 also?)
Or, simply use "pmdumptext cgroup" (but again, better to split up
the clusters to aid diagnosis).
> It's not the batch-fetching aspect of pminfo that made this test
> workable, but its willingness to traverse a PMNS hierarchy.
(the cgroup PMNS itself is static now, so no refreshing done there
anymore of course - its all about the fetch and/or instance PDUs)
Either I'm missing something, or you're missing what is happening
in proc_refresh - it doesn't matter how many PMIDs get thrown at a
single fetch, it will refresh each cluster only once per fetch...
so it has to be the fetch batching that triggers the leak, right?
If so, that's as subtle as anything - too much so for a test, IMO,
and using a different tool seems the better option (for this, and
the other reasons above).
cheers.
--
Nathan
|