This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: precompiled probing scenarios
Frank Ch. Eigler wrote:
Hi -
dsmith wrote:
[...]
Nice work, thank you! You might want to taunt people with some speed
improvement numbers too.
Oops, I forgot to include those. For "make check", the time goes from
29 minutes (when seeding the cache) down to 8 minutes (with cache). For
"make installcheck", the time goes from 56 minutes down to 24 minutes.
[...] The hash is computed using the following data:
- gcc's path, size, and mtime
- stap's version and compile date
In addition or instead of this, could include a hash of /proc/self/exe
content and/or stat info (like gcc's), for us developers.
OK.
[...]
Note that currently several tests in the testsuite fail after a first
run to seed the cache because they don't expect to see the skip from
pass 2 to pass 5.
How do you mean they fail? -p3 or -p4 should still work.
Here's what goes on. The '-p3' and '-p4' options still work. But,
several run ('-p5') tests use testsuite/lib/stap_run.exp or
testsuite/lib/stap_run2.exp. Those two tcl files expect to see "Pass
[12345]" in the output. They get confused when only seeing "Pass [125]"
and then think the test has timed out.
I'm hoping to fix this today.
[...]
- Set a maximum cache size and expire old modules. Is this needed?
We can include a shell script ditty for that. I wouldn't bother put
the logic into stap proper.
OK.
Regarding the choice of cache directory name (".stap_cache"), that's
OK if we don't anticipate anything other than cache files to have to
live under $HOME. But if we want to undertake cross-instrumentation
along the lines I proposed, we'd need at least a few more non-cache
files (for host descriptions for example). If so, then .stap_cache
should be nested as .systemtap/cache instead, so that other data files
may live under .systemtap/.
That sounds reasonable.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)