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]

[Bug testsuite/18577] on rhel7, listing_mode_sanity.exp always gets a failure when doing 'stap -l **'


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.


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