Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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?
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.
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 6RHEL 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.