This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH RFC] introduce dl_iterate_phdr_parallel
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Gleb Natapov <gleb at scylladb dot com>, libc-alpha at sourceware dot org, Jakub Jelinek <jakub at redhat dot com>, Jonathan Wakely <jwakely at redhat dot com>
- Date: Mon, 1 Aug 2016 16:26:20 -0400
- Subject: Re: [PATCH RFC] introduce dl_iterate_phdr_parallel
- Authentication-results: sourceware.org; auth=none
- References: <20160725142326.GM1018@scylladb.com>
On 07/25/2016 10:23 AM, Gleb Natapov wrote:
> Problem: exception handling is not scalable. Attached program mt.cc
> demonstrates this easily. It runs around 1 seconds with 1 thread, but
> with only 4 threads it takes 4.5 seconds to complete. The reason is
> locks that are taken on unwind path.
>
> There are two locks right now.
>
> Fist is in libgcc's _Unwind_Find_registered_FDE and it is eliminated by
> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01629.html (for dynamic
> executables only, but this is common case).
>
> Second one is dl_load_write_lock in __dl_iterate_phdr. It serves dual
> purpose: it stops the list of loaded objects from been modified while
> iterating over it and it makes sure that more than one callback will
> not run in parallel. This means that even if we will find a cleaver way
> to make __dl_iterate_phdr iterate over the objects list locklessly the
> lock will still have to be taken around the call to callback to preserve
> second guaranty.
This is an X Y problem.
I don't think the solution is to add a new dl_iterate_phdr_parallel interface,
but instead to rethink why C++ exceptions need to dl_iterate_phdr at all.
Exactly what information does C++ need and why?
We have been discussing this internally at Red Hat, but I'd like to get your
external opinion on the situation.
> This patch here propose to introduce another API: dl_iterate_phdr_parallel
> which does exactly same thing as dl_iterate_phdr but may run more than
> one provided callback in parallel. And to make it more scalable it
> breaks single dl_load_write_lock into arrays of locks. Reader takes only
> one lock, but writer has to lock all of them to proceed with modifying
> the list.
Do you have copyright assignment for glibc?
https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment
https://sourceware.org/glibc/wiki/Contribution%20checklist
--
Cheers,
Carlos.