This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: LTTng-UST vs SystemTap userspace tracing benchmarks
- From: Roland McGrath <roland at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Julien Desfossez <julien dot desfossez at polymtl dot ca>, ltt-dev at lists dot casi dot polymtl dot ca, systemtap at sources dot redhat dot com, Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>, dominique dot toupin at ericsson dot com
- Date: Wed, 16 Feb 2011 10:19:43 -0800 (PST)
- Subject: Re: LTTng-UST vs SystemTap userspace tracing benchmarks
- References: <4D5AA164.1050607@polymtl.ca> <m37hd06lpj.fsf@fleche.redhat.com>
> The sdt.h stuff has been rewritten at least once since then. I'd
> suggest trying the latest. I think it probably won't matter for the
> flight recorder mode, but it may matter for measuring overhead.
The v3 and v2 versions have the same runtime/code overhead. The
difference is in the data overhead, which includes some startup-time
dynamic linking overhead for PIC code. In v3, there is no data
overhead except possibly the one semaphore word, and none of that
startup-time overhead at all.
> I'd be interested to also see the numbers when the probes are in place
> in the source, but not enabled. That is, what is the overhead of a
> disabled probe?
>
> When doing this with SystemTap it would be interesting to try twice:
> once with a semaphore for each probe, and once without.
In v2 and v3, the only runtime overhead of a disabled probe is the
presence of a single 'nop' instruction in the code path. AIUI, on
modern processors that costs less than one cycle. The overhead of
a probe firing is unchanged, being a full breakpoint trap and the
kernel side of handling that and running the probe machinery.
Thanks,
Roland