This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: stptracer-20060828 has released.
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Li Guanglei <guanglei at cn dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>, "Jose R. Santos" <jrs at us dot ibm dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>
- Date: Fri, 01 Sep 2006 11:55:21 +0900
- Subject: Re: stptracer-20060828 has released.
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
- References: <44F58A51.6060806@hitachi.com> <44F69E3C.10308@cn.ibm.com>
Hi,
Li Guanglei wrote:
> The first thing I want to figure out about STPTracer is how it
> performs compared with LKET. STPTracer uses an interface named gBTI
> which could only print fix number integers into a pre-reserved relayfs
> buffer, while LKET uses the _stp_printf with binary print support.
It's interesting. Thank you for the benchmarking.
> <1> run app_getsid with being probed:
> cpu 0: loops=5000000, average=442 ns
>
> <2> run app_getsid with an stp script with empty probe handlers, i.e.,
> probe syscall.getsid {}
> cpu 0: loops=5000000, average=1523 ns
>
> <3> probe using lket_getsid.stp:
> cpu 0: loops=5000000, average=3079 ns
>
> <4> probe using lkst_getsid.stp:
> cpu 0: loops=5000000, average=2341 ns
I checked that by a similar benchmark(I used gettimeofday, instead of getsid)
<1> no probe handler
148 ns
<2> empty probe handler
406 ns
<3> lket probe handler
865 ns
<4> gbti probe handler
589 ns
The overheads are depends on architecture.
I measured on athlon64 (with ia32 mode kernel).
> Here you can see that gBTI is around 23% faster than _stp_printf(). In
> fact a long time ago I used oprofile to find out where _stp_printf()
> cost cpu time, and it showed that a lot time is spent on _stp_vsnprintf().
>
> So we use _stp_printf() for its fancy printing format in trade of its
> slower speed compared with gBTI. But the interface like gBTI imposes
> too much restriction on trace data format and the number of data items
> to be traced. Maybe we should find some places inside _stp_printf()
> for further performance improvement while still have the capability to
> print data freely.
I agree.
Thanks,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com