This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [PATCH] libdw: add thread-safety to dwarf_getabbrev()
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Jonathon Anderson <jma14 at rice dot edu>
- Cc: Mark Wielaard <mark at klomp dot org>, elfutils-devel at sourceware dot org, Srdan Milakovic <sm108 at rice dot edu>
- Date: Sat, 26 Oct 2019 18:50:30 +0200
- Subject: Re: [PATCH] libdw: add thread-safety to dwarf_getabbrev()
- References: <1565983469.1826.0@smtp.mail.rice.edu> <20190824232438.GA2622@wildebeest.org> <1566695452.979.1@smtp.mail.rice.edu> <5ba06557703ee363e19488c994cbddd92ade25be.camel@klomp.org> <1566782688.5803.0@smtp.mail.rice.edu> <ba2c453b09ddac529a3aa122402380f5d7f82b2a.camel@klomp.org> <1566826627.5246.0@smtp.mail.rice.edu> <1566877968.10901.0@smtp.mail.rice.edu> <87tv7vg4l0.fsf@mid.deneb.enyo.de> <8fde453a2c570fa150aa39b0dabd0f925c7b0970.camel@klomp.org> <1572108332.6121.0@rice.edu>
* Jonathon Anderson:
>> This assumes that memory allocation
>> is actually a performance problem, otherwise you could let malloc
>> handle the details.
>
> In our (Dyninst + HPCToolkit) work, we have found that malloc tends to
> be slow in the multithreaded case, in particular with many small
> allocations. The glibc implementation (which most of our clients use)
> uses a full mutex to provide thread-safety. While we could do a lot
> better in our own projects with regards to memory management, the fact
> remains that malloc alone is a notable facet to the performance of
> libdw.
Current glibc versions have a thread-local fast path, which should
address some of these concerns. It's still not a bump-pointer
allocator, but at least there are no atomics on that path.
I'm not sure if it is prudent to code around imperfections in older
allocators.