Re: [pcp] suitability of PCP for event tracing

[nathans at aconex dot com]

Hi Ken,

----- "Ken McDonell" <kenj@internode.on.net> wrote:
> 
> I've been mulling over this issue (and the related matter of "missed"
> event records, where I don't think the implementation is sufficiently
> flexible).
> 
> I think _anything_ related to event records has to map onto a
> pmResult ... this is the only way avoid auxiliary data structures for
> pmUnpackEventRecords(), but _more_ importantly when pmlogextract
> knows
> how to unroll an archive and get all of the original pmResults and
> the
> event records pmResults temporally sorted in a single output archive
> the _only_ place to hide information will be in a pmResult.

OK, yep, makes sense.

> Try this one for size ...
> 
> Add a new sort of "anonymous" PCP metric, such that the PMID is
> hard-coded for a small number of anon metrics as is the pmDesc (I'm
> thinking one per simple data type, semantics discrete, no units, no
> instance domain) and the "name", e.g. anon.u32 for a PM_TYPE_U32
> metric with pmid 0:0:1.
> 
> Domain #0 is unused, so we have a convenient place in the range of
> PMIDs.

Yeah, sounds like this could indeed work & would be alot more flexible.
Not sure about the name "anon", nor the one metric per type, wouldn't
it be better to have specific metrics for the specific items we know we
need (so far, nmissed and flags, both of which would be u32 as well).
Then we can make the units/semantics/type make sense too.

And meaningful names like event.record.missed and event.record.flags
(or something like that) might give a bit more of a clue as to what
they are than anon.

> I'd appreciate thoughts on this.

Yep, I like the general idea, maybe with some cosmetic tweaks as above?

cheers.

-- 
Nathan