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

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Tue, Sep 04, 2007 at 12:29:34PM -0700, Mike Mason wrote:

> [...]  And, yes, it wouldn't be faster overall, but it would allow
> us to reenable interrupts faster in some cases.

That's probably true.  Interestingly, the "stap -t" (benchmark) option
lets one see the total amount of time (cycles) during which interrupts
were disabled due to systemtap.

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

Sometimes kprobes skips probes for us due to reentrancy or whatnot.
We toss them into the same "skipped" bucket for reporting purposes.

> Also, why do we only use per cpu variables for aggregations?  Is it
> because of memory concerns or something more than that?

It's specifically not for memory concerns.  It's to increase available
parallelism, with different CPUs *adding* data to aggregations
concurrently with <<<.  (In contrast, *reading* data with @count
etc. requires cross-cpu synchronization - modeled by exclusive locks -
to produce meaningful data.)

- FChE