Re: Why systemtap loses events and what can be done about it?

[Mike Mason <mmlnx at us dot ibm dot com>]

Frank Ch. Eigler wrote:
> Hi -
>
> On Tue, Sep 04, 2007 at 09:48:13AM -0700, Mike Mason wrote:
>
> > I've been toying with the idea of optimizing probe handlers by
> > implementing them like interrupt handlers, with top and bottom
> > halves.  [...]
>
> This is unlikely to be faster overall, but is an interesting idea.
> Putting blocking-capable constructs into a deferred-work handler could
> be an explicit option, though wrought with risks.  (Lack of
> synchronization is one: a deferred get_user() value may not resemble
> one possibly fetched at the instant of a raw probe point.)

I was thinking specifically of using d_cookies and work queues to safely defer getting full pathnames, similar to what oprofile does.  I don't know if a similar approach would work for other data.

You're right, any data that can change between the top and bottom halves would have to be collected in the top half.  And, yes, it wouldn't be faster overall, but it would allow us to reenable interrupts faster in some cases.  I originally thought that might reduce the number of skipped probes, but now realize I was probably mistaken.

Refresh my memory... are skipped probes only an indication of the number of probes that timed out on locks or are probes skipped for other reasons?  Also, why do we only use per cpu variables for aggregations?  Is it because of memory concerns or something more than that?

Mike

> - FChE