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 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.



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