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: Gleb Natapov <gleb at scylladb dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: 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 23:52:12 +0300
- Subject: Re: [PATCH RFC] introduce dl_iterate_phdr_parallel
- Authentication-results: sourceware.org; auth=none
- References: <20160725142326.GM1018@scylladb.com> <537b0b89-d205-4d83-90ee-e94647c4d737@redhat.com>
On Mon, Aug 01, 2016 at 04:26:20PM -0400, Carlos O'Donell wrote:
> 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.
>
It becomes a little bit late here, let me get back to you about it
tomorrow.
> > 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?
As far as I know yes. I'll check this tomorrow. If this is the same one
as for gcc then definitely yes (as a company ScyllaDB, not as individual
contributor).
>
> https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment
>
> https://sourceware.org/glibc/wiki/Contribution%20checklist
>
> --
> Cheers,
> Carlos.
--
Gleb.