This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug testsuite/18577] on rhel7, listing_mode_sanity.exp always gets a failure when doing 'stap -l **'
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 25 Jun 2015 15:14:48 +0000
- Subject: [Bug testsuite/18577] on rhel7, listing_mode_sanity.exp always gets a failure when doing 'stap -l **'
- Auto-submitted: auto-generated
- References: <bug-18577-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18577
David Smith <dsmith at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from David Smith <dsmith at redhat dot com> ---
Fixed in commit cff6336.
That commit fixes 2 sources of 'stap -l **' slowness:
1) If we're in either of the listing modes (-l/-L) and the verbose level is
less than 2, we're generating the alternatives list... and then throwing it
away.
So, to make things faster, if we're in either of the listing modes and the
verbose level is less than 2, we no longer try to generate the alternatives
list at all.
2) So, why are we trying to generate alternative lists in the first place?
Because we've got semantic errors in the tapsets. But, we don't really have
semantic errors in the tapsets, only because of the way 'stap -l **' expands
everything. Here's an example (with the probe's guts removed):
====
probe syscall.pipe = __syscall.pipe2 ?, __syscall.ia64_pipe ?, __syscall.pipe
{}
probe __syscall.pipe2 = kernel.function("sys_pipe2").call
{}
probe __syscall.ia64_pipe = kernel.function("sys_ia64_pipe").call
{}
probe __syscall.pipe = kernel.function("sys_pipe").call
{}
====
So, the syscall.pipe probe alias has 3 possible locations, 2 of them being
optional. So, if you use syscall.pipe you'll be fine. However, if you used
__syscall.pipe2 and your kernel doesn't have sys_pipe2, you'll get an error.
The same thing would happen with __syscall.ia64_pipe.
'stap -l **' tries to expand all probe aliases, including the "internal" ones
starting with '__'.
To workaround this, I changed the above to:
====
probe syscall.pipe = __syscall.pipe2 ?, __syscall.ia64_pipe ?, __syscall.pipe
{}
probe __syscall.pipe2 = kernel.function("sys_pipe2").call ?
{}
probe __syscall.ia64_pipe = kernel.function("sys_ia64_pipe").call ?
{}
probe __syscall.pipe = kernel.function("sys_pipe").call
{}
====
That works by making __syscall.pipe2 and __syscall.ia64_pipe optional. So,
there aren't any errors there that need alternatives listed.
However, there are some probe aliases that have a similar problem that can't be
fixed:
====
probe nfs.aop.write_end = __nfs.aop.write_end !,
__nfs.aop.commit_write
{}
probe __nfs.aop.commit_write = kernel.function ("nfs_commit_write") !,
module("nfs").function ("nfs_commit_write")
{}
====
Here, I can't make module("nfs").function("nfs_commit_write") optional, since I
want an error here if no targets can be found for the nfs.aop.write_end probe
alias.
With the above 2 fixes, I'm now seeing the following times for 'stap -l **' on
that same RHEL7 VM:
====
# time stap -l '**' > /dev/null ; echo $?
real 2m33.532s
user 2m48.206s
sys 0m19.263s
0
dsmith@kvm-el7-64-1: rhel7-64 50 -> time stap -l '**' > /dev/null ; echo $?
real 1m46.183s
user 1m43.278s
sys 0m2.750s
0
====
So, we're seeing run times less than 3 minutes. That's much better than 15
minutes.
--
You are receiving this mail because:
You are the assignee for the bug.