Re: Systemtap performance impact on N800

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

Hi -

On Wed, May 14, 2008 at 08:23:57AM -0400, Bruno Abinader wrote:
> Hi Frank,
> Thank you for the valuable feedback. Some comments below:
> [...]
> >  Thanks for running these tests.  One important thing to watch out for
> >  is that you're comparing apples to apples.
> >  [...]
> I've looked into the k-009.c code (from section 2.2.3) and noticed
> that kretprobes implementation was missing, so I've fixed it (inserted
> kretprobes code into it) and now the Kprobes-only implementation has
> probes on begin and end of do_gettimeofday function. It is interesting
> to notice that with this modification, kprobes results took a higher
> value, from 3 to 5 seconds, approaching to actual systemtap results.

Yes, that makes a lot of sense.  The overhead that systemtap creates
(that is, beyond kprobes/kretprobes dispatching) is actually quite
small - as one can guess from looking at a "stap -p3" code dump.


> As for section 3.2, there is really no kprobe source. We made some
> confusion at the time of writing the document and put it there, but
> the only results were made for these scenarios:
> - default kernel
> - kprobes (not used)
> - kprobes + systemtap
> - oprofile

I don't understand then what you're trying to compare here.  Is it the
degree to which the system slows down if some arbitrary systemtap
script is running, as compared to a different and arbitrary oprofile
collector? If the conclusion limited itself to "some systemtap scripts
can slow the system down somewhat", that'd be fine.  However, you
appear to compare different instrumentation systems to each other when
they're doing completely different data gathering, and this seems
meaningless.


- FChE