pmachata.threads branch status
by Petr Machata
Hi,
I found a couple cases in libelf that look like they need some extra
locking. I assumed that the client has control over the lifetime of Elf
structures, which is to say that I didn't try to fix the race between
releasing memory allocated for struct Elf in one thread, and trying to
lock the same Elf in other thread.
The changes are on pmachata.threads branch.
PM
14 years, 9 months
Inline instance cache
by Petr Machata
Hi,
I had a chat with Frank sometime ago, and he presented a couple
scenarios where Systemtap takes extremely long to compile the script.
He expressed a wish that performance tweaks be done on elfutils side.
Hence this mail.
For starters, the following scenario:
$ time ./stap -p2 -e 'probe process("/usr/bin/inkscape").function("*")
{}' &> out2
real 2m47.944s
user 2m42.157s
sys 0m5.165s
It turns out that most of the time is spend iterating inline instances
(dwarf_func_inline_instances). So I created a straightforward cache
that simply finds all the inline instances in given CU, and stuffs them
into one array. It's a quick work, I just want opinions before I end up
inventing crazy caching schemes in a wrong place.
So when the cache is ready, all future calls simply iterate over this
array. In case of inkscape, this crude cache improves stap startup time
by a factor of 10. Other binaries give varying results, e.g. on
/usr/bin/stap it improves the startup time by factor of ~15. Small
binaries (or binaries with small number of inline instances, e.g.
gimp-2.4) tend to break even, the cache just doesn't make a difference.
The cache needs two Dwarf_Die entries per one instance (one for the
instance itself, the other for the abstract origin; even though it only
needs the address of the abstract origin). Per my measures (done on
i386), stap needs ~700K for the cache itself, Inkscape ~4.5M (whole
debuginfo has 60M), gimp ~50K. I haven't looked what's the memory
consumption of other parts of the elfutils, but this seems to be quite a
lot. Only storing a word for origin address would cut 3/8 from that.
Please comment. The code sits on pmachata.stap branch.
Thanks,
PM
14 years, 11 months
Re: com.redhat.elfutils.roland.pending review
by Ulrich Drepper
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've propagated the changes and fixed a minor problem in i386_reloc.def.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkjn1MgACgkQ2ijCOnn/RHRqswCZAV+h1my/1NYBu4AIt9cGoO3H
VCcAn0/7x37dUcvBcNGll0e+LlwMoOst
=3Ygj
-----END PGP SIGNATURE-----
14 years, 11 months