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:

> Nathan,
> 
> Thanks for the feedback.

No worries.  Thanks for the examples, big help.

> On Mon, 2010-10-11 at 23:33 +1100, Nathan Scott wrote:
> > ----- "Ken McDonell" <kenj@internode.on.net> wrote:
> > 
> > > It has taken me a while to work through all of the issues here,
> not
> > > to
> > > mention more distractions than you could hit with a big stick.
> > > 
> > > Anyway putting an array of event records inside a pmResult is not
> > > going to be too hard - see
> http://oss.sgi.com/~kenj/event-params.html
> > 
> > | Event trace data includes the following for each event:
> > | timestamp
> > | event type
> > | event parameters (optional)
> > | The event type is really just another event parameter so we will
> not
> > | consider this as a separate data type, and event data consists of
> a
> > | timestamp and one or more parameters.
> > 
> > IMO, we also need Unique ID (refer X-trace and Dapper papers) and
> parent ID.
> > Preferably not optionally (could be inserted in PCP layers if no
> underlying
> > tracing support for end-to-end style tracing.
> 
> I don't think tree-structured traces as in X-trace or Dapper are
> sufficiently generic that they warrant explicit support in the PCP
> infrastructure.  I've looked at the X-Trace data model, and it maps

Hmmm, not yet completely convinced because...

> simply to the PCP data model (TaskID is simply an event parameter
> that is repeated and has the same unique value in all events that are part
> of the same tree).
> 
> I've updated the proposal document to include some examples,
> including X-Trace.

Ah, thats great, esp. the strace example.  The problem I think we have
there is that there is no distinction between start and end of an event
and no way to say "this event completes that earlier event".

If we dive a bit deeper into the strace example, that's implemented on
Linux using ptrace(PTRACE_SYSCALL,...) - and the start (syscall addr &
args) and end (return code) are separately generated trace events ... I
think we really need to preserve that notion (2 separate events, in PCP,
not merging 'em into just one at the end) and so some mechanism will be
needed to be able to associate the two events later (a unique ID, ala
X-Trace/Dapper might be the go).  Perhaps this can be a mandatory metric
- 62.0.0 in strace example, before syscall ... not sure, but still seems
to me like its needed.

Following on from that, its not clear if PM_TYPE_EVENT is enough, we may
need START/IN-PROGRESS/FINISH granularity too, so client tools can make
sense of the flow for presenting the data sensibly.

> > I think in practice this will prove a bit optimistic (so much data,
> classifying
> > it all - all parameters, flags, etc - to the tight PCP definitions
> ... not sure
> > this is really feasible, or needed). ...
> 
> The number of classifications may be quite small, e.g. the generic
> data
> types in the strace example.  We don't need to capture deep semantics
> here, but there is some advantage in capturing shallow semantics.  I
> suspect that the tools that process the data are the places where the
> deep semantics is needed, and this is likely to be embedded within
> those applications rather than the PCP data stream.
> 

On this one, the strace example has convinced me its doable & indeed,
as you say, the tracing PMDA author can choose the level of granularity
and/or build it up over time (e.g. on strace again, start with a core
set of syscalls of interest which are explicitly decoded, and for the
rest pass out an AGGREGATE and/or just the syscall identifier.

> > ...
> > I think a composite metric type like JSON
> ....
> This is not precluded by the proposal ... we can encode arbitrary
> strings as the "parameters" of an event if that makes most sense.

*nod*

cheers.

-- 
Nathan


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