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


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


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