This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [pcp] suitability of PCP for event tracing


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]