This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH RFC] introduce dl_iterate_phdr_parallel



On 25/07/2016 11:23, 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 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.

Wouldn't a read-write lock solve the performance problem at dl_iterate_phdr?
It should scale better than current code, since dl_iterate_phdr should act
just a reader on link_map structures and multiple readers should only incur
in a lll_lock/lll_unlock on rwlock->__data.__lock.  I am assuming that
we set it to prefer readers and use a read-lock on dl_iterate_phdr.

I see this slight better than trading memory and a limited scalability 
(the _DL_LOCKS value) and also avoid adds another exported API.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]