----- Original Message -----
>
> nathans wrote:
>
> > [...] One final suggestion - it occurred to me while looking over
> > pmcd_probe once more that the existing tracing had a split between
> > pdu vs non-pdu trace traffic. It would possibly be easy to maintain
> > that in these probes, such that one can choose to (eg) not wear the
> > pdu traffic trace cost, just the other lower-volume tracing. [...]
>
> I see what you mean. The tracing-disabled costs for both options are
> zero, so what's worth comparing are the tracing-activated ones. In
> the case in point, if one was not interested in PDU tracing, one'd
> still pay a couple of microseconds per PDU to filter out the event.
> If e.g. these PDU events occur orders of magnitude more frequently
> than the others, it may well be worth it to separate them.
*nod* - yes, it will be, the PDU events will swamp the rest for sure
under normal circumstances. Turned out there's not much code change
needed to finish that patchlet off, so I've done it now. If there's
tapset changes needed Stan (which almost certainly there is), could
you take care of that? (also be aware of the change from below...)
Also, the build failed in a couple of spots on Mac OS X - firstly,
the syntax of our probes.d file was not valid there - "probes" is a
keyword, so:
provider probe {
probe PMCD ...
}
was not allowed (the first occurrence there was a problem). I've made
this now "pcp_probe", seems to have made things happy. Then, the way
the .o file is built and linked appears unnessary with dtrace, the -G
option in particular ... so, I've made that object file creation and
linking Linux-specific (which ISTR from last time I played with dtrace
on a Mac, worked out well back then).
cheers.
--
Nathan
|