[pcp] suitability of PCP for event tracing
Ken McDonell
kenj@internode.on.net
Thu Sep 16 12:40:00 GMT 2010
On 16/09/2010 12:07 PM, Greg Banks wrote:
> Frank Ch. Eigler wrote:
> ...
>> Or do you imagine a pure polling-based API all around, with buffering
>> latencies at the intermediate layers?
>>
>>
> This could be made to work too.
I think we should pursue the discussion this approach a little further.
There is only one layer of buffering needed, at the PMDA.
So far, the obstacles to this approach would appear to be ...
1. Need buffer management and per-client state in the PMDA (actually it
is per PMAPI context which is a little more complicated, but doable) ...
I don't see either issue as a big deal, and together they are order of
magnitude simpler than supporting the sort of asynchronous callbacks
from PMCD that have been suggested.
2. Latency for event notification ... the client can control the polling
interval (down to a few milliseconds demonstrably works), so I expect
you'd be able to tune the latency to match the semantic demands. If
really low latency is needed then any TPC-based mechanism is probably
not going to work well, and PCP may be the wrong tool for that space.
3. Each pmFetch may return none, one or many event records. None is not
a problem, but to support many we need to devise an encapsulated data
aggregate within a pmResult that stores event parameters (including
timestamps I suspect) as first order citizens in terms of pcp metadata
... I don't think this is hard either.
I believe this approach would ...
a. allow event trace data to be intermixed with classical PCP data
coming from PMCD to a PMAPI client
b. move the threadsafe PCP libraries work off into something that can be
tackled independently (and probably should be done as the benefits are
more general)
c. does not break any existing PMDAs or PMAPI clients
d. be doable in a very short time ... for instance wrapping an array of
events inside a "special" data aggregate is simple and isolated, and
there is already the basis for the required PMCD-PMDA interaction to
ensure the context id is known to the PMDA, and the existing context
cleanup code in PMCD provides the place to notify PMDAs that a context
will no longer be requesting events.
So, can anyone mount a convincing argument that the requirements would
demand changes to allow asynchronous behaviour between PMAPI clients
<---> PMCD <---> PMDAs?
If not, I strongly suggest we work to flesh out the changes needed to
make a variable length array of structured event records avaliable
through the existing poll-based APIs.
More information about the Systemtap
mailing list