[pcp] suitability of PCP for event tracing

[Ken McDonell]

On 17/09/2010 12:24 AM, Frank Ch. Eigler wrote:
> ...
>
> OK.  This suggests two separate steps: allowing more than one
> separately-timestamped metric tuple to come back from the new
> array-fetch functions; and to allow structured data through some new
> metric data type.

Yep.  I have a design for this ... it is in HTML, so won't go to the 
systemtap list ... I'll be home Mon next week and I'll put the document 
someplace where others can find it.  It is not very complicated and 
should be easy to implement.

I am assuming there is at most one source of event records per PMDA, 
which I think is OK (event records are of variant type, with the number 
of parameters being different, possibly based on event type) ... if 
there were two independent sources of event records, I think they'd have 
two different (kernel) APIs for registration and extraction and would 
sensibly belong in two different PMDAs.  Please let me know if this 
assumption is not likely to be correct/acceptable.

> For the former, it seems we'd need at least three functions in pmapi.h
> to be forwarded to the pmda: one to start watching metrics of
> interest, one to poll any values collected since last time, and one to
> shut down the watch.

I have not considered the register (and filter if they are separate) and 
unregister functions.  pmStore is the existing way to push this sort of 
thing to a PMDA.  Since I don't think there is a generic syntax for 
event registration and filtering, this probably needs to be opaque to 
PCP and known by the client and the PMDA, e.g. magic integers, strings, 
....  pmStore leverages existing protocols and can be used to both start 
watching (register in my speak) and shutdown (unregister in my speak). 
Is there something else that is needed that could not be implemented 
using pmStore and "control" variables to set (and possibly return) the 
status/profile/registration of current events of interest?

We do need additional PMCD <--> PMDA protocols for the context id 
information and this will provide the hook for the cleanup in the case 
where the client chooses to die, rather than unregister their event 
collection(s).   8^)>

There is no need to poll ... pmFetch will return a pmResult with numval 
indicating if there are any event records in the pmResult payload.

> For the pmda side, since main thread control is to stay elsewhere,
> asynchronous data collection would seem to require multithreading in
> the typical cases, but perhaps not initially.

Agreed.  But provided the thread catching and cacheing the events does 
not call any PCP libraries, we're OK with the libraries as they stand 
... there are several existing PMDAs built this way.  We just need 
conventional mutex guards to protect the shared data structures that 
hold the cached events ... simple single producer and single consumer stuff.