Re: [PATCH RFC] introduce dl_iterate_phdr_parallel

[Gleb Natapov <gleb@scylladb.com>]

On Wed, Aug 03, 2016 at 11:00:39AM -0300, Adhemerval Zanella wrote:
> 
> 
> On 03/08/2016 07:53, Florian Weimer wrote:
> > On 08/01/2016 09:46 PM, Torvald Riegel wrote:
> >> The new rwlock is built so that it supports process-shared usage, which
> >> means that we have to put everything into struct pthread_rwlock_t.  This
> >> will lead to contention if you rdlock it frequently from many threads.
> >> There is potential for tuning there because we haven't looked closely at
> >> adding back-off in the CAS loop (and if you tested on an arch without
> >> direct HW support for fetch-add, the CAS loop used instead of that might
> >> also be suboptimal).
> > 
> > The rwlock doesn't eliminate the contention at the hardware level.
> > 
> > If that causes a performance issue, we could reuse Ingo Molnar's brlock approach: per-thread, readers acquire their own lock, writers acquire the locks of all threads.  This is fairly efficient in the read case (and I suspect you can't get much better than that in a non-managed run tine), but the write case is obviously extremely costly.  This could be the right trade-off here, though.
> > 
> > Florian
> 
> The only difference is lglocks/brlocks are per-cpu in kernel, not per-thread.
I proposed the same algorithm that Florian describes somewhere in this
thread as an alternative too. Linux kernel does similar trick in mmu
notifiers code (search for mm_take_all_locks), but I wouldn't go this
more complicated route until it is proven that current version has
scalability problems.

> My concern is what kind of writer degradation it could be in a highly threaded
> workload (for instance, a threaded c++ workload with some exceptions that tries
> to load a plugin).
> 
The forward progress of plugin loader is guarantied.

> It could be the case a constant write lock array, as the initial proposal, could
> be a better initial proposal. 
Agree 100%.

--
			Gleb.