This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [pcp] suitability of PCP for event tracing
- From: nathans at aconex dot com
- To: Ken McDonell <kenj at internode dot on dot net>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Greg Banks <gnb at evostor dot com>, systemtap at sources dot redhat dot com, pcp at oss dot sgi dot com
- Date: Sun, 19 Sep 2010 20:19:08 +1000 (EST)
- Subject: Re: [pcp] suitability of PCP for event tracing
----- "Ken McDonell" <kenj@internode.on.net> wrote:
> On 17/09/2010 9:18 AM, nathans@aconex.com wrote:
> > ...
> I _do_ think this is simple
> - doubly linked list (or similar) of events
> - reference count when event arrives based on number of matching
> client
> registrations
> - scan list for each client gathering matching events, decrementing
> reference counts
> - free event record when reference count is zero
> - tune buffer depth per client with pmStore
> - cull list if client is not keeping up and return PM_ERR_TOOSLOW
OK. Obviously, will need to encapsulate that in a generic library
(likely libpcp_pmda) for all types of trace PMDA... but, thats kinda
obvious. Sounds good, worth a shot. I think we may also need to
provide a PMDA-side mechanism to ensure memory use doesn't grow out
of control on PMDA side even if clients are keeping up, but that we
can trial in practice.
> Plus several variants around lists per client or bit maps per client
> to
> reduce matching overhead on each pmFetch.
>
> If my battery would last long enough, I think this could be done on a
>
> plane between Copenhagen and Melbourne!
>
Sounds optimistic to me... consider it a challenge. :)
>
> I think you'd need my "expand PM_TYPE_EVENT into a set of pmResults"
> change to pmlogger to get close here. But even with that, I'm not
> sure
> what pmchart is going to do with event data records having timestamps
> of
> 9:45:03.456, 9:45:03.501, 9:45:04.001, etc. The event parameters are
> likely to be discrete, so the semantics is going to be hard for pmchart.
I think it will be able to handle it OK (with changes, but it all
sounds doable so far). I suspect we can even make a decent stab
at presenting the formatted trace data there too (though not inline
in the actual charts).
> > ... Well, actually, not sure how this will look? - does a
> > trace have to end before a PMDA would see it? that'd be a bit
> lame;
> > or would we export start and end events separately? ...
>
> This depends on the underlying event tracing subsystem. Some emit
Good. I just wanted to be sure its not dependent on the PMDA / libpmda.
>
> Not sure I follow. I'm expecting the events to be emitted once
> tracing
> is activated (or an interest is registered), so I'm not sure the
> concept
> of "trace X is in-progress" will be visible outside the PMDA.
Good stuff.
>
> > Could extend the existing temporal index to index start/end time
> for
> > traces so we can quickly find whether a client sample covers a
> trace?
> > Either way, I suspect "trace start" and "trace end" may need to
> each
> > be a new metric type (in addition to PM_TYPE_COUNTER,
> PM_TYPE_INSTANT
> > and PM_TYPE_DISCRETE that we have now, iow).
>
> I think we need some input from those on the list likely to be the
> generators of the events, as it seems Nathan and I don't have a common
> view on what data is going to be emitted. In my mind, there are event
>
I'm mostly just wondering out loud, don't take my earlier mail as any
disagreement. :)
cheers.
--
Nathan