This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: "lttng comparison with other tracers" page


Hi -


On Tue, Mar 17, 2009 at 04:41:31PM -0400, Mathieu Desnoyers wrote:
> [...]
> I am trying to build and run systemtap on markers (on top of the LTTng
> tree), and here is the result (for with system 0.9 and the current git) :

Thanks for trying!


> Tree : 2.6.29-rc8 lttng 0.112
> On x86_64
> 
> ./configure
> make
> [....]
> So I try disabling PIE :

Yup, we're tracking this problem as
<http://sourceware.org/bugzilla/show_bug.cgi?id=9922>.


> make clean
> ./configure --disable-pie
> make
> make install
> 
> ok:/usr/local/bin# ./stap -e 'probe kernel.trace("*") {}' -w -t
> semantic error: cannot get type of tracepoint 'swap_in' parameter 'entry'
> Pass 2: analysis failed.  Try again with another '--vp 01' option.
> The swap_in tracepoint has the following parameters :
> void probe_swap_in(struct page *page, swp_entry_t entry)

I believe this can happen if the tracepoint declaration header file
does not #include all the headers needed to declare all of its types.
This is probably a problem worth fixing in your files.  Is that right,
Josh?


> ok:/usr/local/bin# ./stap -e 'probe kernel.mark("*") {}' -w -t
> Pass 4: compilation failed.  Try again with another '--vp 0001' option.

That should also have worked.  Maybe the marker API in your tree has
changed incompatibly with what else we've ported systemtap against.


> So I created a small script that enables only part of the lttng
> instrumentation, ran with stap -t -w scripname :
> 
> probe kernel.trace("irq_entry") {}
> probe kernel.trace("irq_exit") {}
> probe kernel.trace("syscall_entry") {}
> probe kernel.trace("syscall_exit") {}
> probe kernel.trace("sched_switch") {}
> probe kernel.trace("sched_process_fork") {}
> probe kernel.trace("sched_process_wait") {}
> probe kernel.trace("sched_process_free") {}
> probe kernel.trace("sched_process_exit") {}
> 
> And as soon as I start the tbench test, stap stops with :
> 
> WARNING: Number of errors: 0, skipped probes: 101
> WARNING: Skipped due to reentrancy: 101

You can try rerunning with -DMAXSKIPPED=99999 ish.  Josh was also
tracking down a problem with this area - is there a bz# for this one
yet?


> So I removed the irq_entry/irq_exit instrumentation to get something to
> work, and got the following tbench result :
> 1658.12 MB/sec
> for the tbench 8 thread test. Without any script activated, the
> throughput is 1901.06 MB/sec, for a performance impact of about 12% for
> incrementing a simple counter. 

OK.

> I wonder what would be the impact if we need to do any calculation
> and access the tracepoint parameters.

WIth current code, it would certainly be more.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]