| Summary: | systemtap.base/cmd_parse.exp: 16 PASS -> 1 FAIL on i686 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Muller <pmuller> |
| Component: | systemtap | Assignee: | Frank Ch. Eigler <fche> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-tools-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | mjw, ohudlick |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-06 15:14:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 682670 | ||
|
Description
Petr Muller
2011-03-29 09:55:21 UTC
Happens on x86_64 too. 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. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |