Re: [PATCH RFC] introduce dl_iterate_phdr_parallel

[Gleb Natapov <gleb at scylladb dot 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.