Bug 691700 - systemtap.base/cmd_parse.exp: 16 PASS -> 1 FAIL on i686
Summary: systemtap.base/cmd_parse.exp: 16 PASS -> 1 FAIL on i686
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: systemtap
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Frank Ch. Eigler
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 682670
TreeView+ depends on / blocked
 
Reported: 2011-03-29 09:55 UTC by Petr Muller
Modified: 2016-09-20 02:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-06 15:14:52 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Petr Muller 2011-03-29 09:55:21 UTC
Description of problem:
The RHEL6.1 candidate systemtap packages has 1 FAIL, 15 PASSes in systemtap.base/cmd_parse.exp testcase, while the 6.0.z systemtap has 16 PASSes here. This happens on i686, it does not happen on ppc64, unknown on s390x and x86_64

Version-Release number of selected component (if applicable):
Environment:
kernel-2.6.32-122.el6
elfutils-0.152-1.el6
systemtap-testsuite-1.4-4.el6

Systemtap:
systemtap-1.2-11.el6_0 PASS
systemtap-1.4-4 FAIL

How reproducible:
always

Steps to Reproduce:
1. cd /usr/share/systemtap/testsuite/
2. make RUNTESTFLAGS=systemtap.base/cmd_parse.exp installcheck
3.
  
Actual results:
FAIL

Expected results:
PASS

Additional info:
It seems to be a timeout on this command: 'stap -l vm.*'

Indeed:

systemtap-1.2-11.el6_0:
# time stap -l vm.*
<snip>
real    0m3.207s
user    0m2.466s
sys     0m0.836s

systemtap-1.4-4:
# time stap -l vm.*
<snip>
real    1m3.260s
user    0m45.645s
sys     0m21.606

Comment 2 Petr Muller 2011-04-01 12:11:48 UTC
Happens on x86_64 too.

Comment 3 Mark Wielaard 2011-04-02 19:06:11 UTC
I assume the time difference might be explained by caching versus non-caching.
Does stap -l vm.* still take that long against 1.4-4 on the second run?

If it is just timing, does it pass when you increase the following timeout
in /usr/share/systemtap/testsuite/systemtap.base/cmd_parse.exp 

spawn stap -l {vm.*}
expect {
    -timeout 60
    -re "vm.*" {pass "cmd_parse8"}
    timeout {fail "cmd_parse8: unexpected timeout"}
    eof {fail "cmd_parse8: unexpected EOF"}
}
wait;catch {close}

Say from 60 to 120.

If not, could you run make RUNTESTFLAGS=systemtap.base/cmd_parse.exp installcheck
again and attach the systemtap.log file?

Comment 4 Petr Muller 2011-04-04 12:57:20 UTC
Second run is quick, so it is solved by caching, but that does not explain the speed hit in the first place. Old systemtap was not that slow even with cold cache (these are i686 results: ppc & s390x have a perf hit with old systemtap and cold cache, but not as painful: 20-30s).

NEW:
# rm -rf ~/.systemtap/cache/*
# time stap -l vm.* > /dev/null // cold cache, slow
real    1m20.625s
# time stap -l vm.* > /dev/null // warm cache, fast
real    0m1.499s
# time stap -l vm.* > /dev/null // still warm cache, fast
real    0m1.512s
# rm -rf ~/.systemtap/cache/* 
# time stap -l vm.* > /dev/null // cold cache again, slow
real    1m20.509s

OLD:
# rm -rf ~/.systemtap/cache/*
# time stap -l vm.* > /dev/null // cold cache, slow
real    0m2.789s
# time stap -l vm.* > /dev/null // warm cache, fast
real    0m0.989s
# time stap -l vm.* > /dev/null // still warm cache, fast
real    0m0.955s
# rm -rf ~/.systemtap/cache/* 
# time stap -l vm.* > /dev/null // cold cache again, slow
real    0m2.613s

systemtap.base/cmd_parse8 PASSes with 120 second timeout.

Comment 5 Frank Ch. Eigler 2011-04-06 15:05:37 UTC
New systemtap looks for more tracepoints and more aggressively than
the previous, but I'm not able to reproduce this slowdown.  As the
code still works, but the testsuite needs a little more time, let's
defer this.

Comment 6 RHEL Program Management 2011-04-06 15:14:52 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


Note You need to log in before you can comment on or make changes to this bug.