elfutils-devel October 2008

elfutils-devel@lists.fedorahosted.org

3 participants
3 discussions

pmachata.threads branch status
by Petr Machata 04 Dec '08

04 Dec '08

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

3 2

Inline instance cache
by Petr Machata 10 Oct '08

10 Oct '08

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

3 4

Re: com.redhat.elfutils.roland.pending review
by Ulrich Drepper 04 Oct '08

04 Oct '08

-----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-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel October 2008