Excessive calls to iterate_phdr during exception handling

[Torvald Riegel]

On Thu, 2013-05-30 at 11:28 +0200, Jakub Jelinek wrote:
> On Thu, May 30, 2013 at 11:21:08AM +0200, Torvald Riegel wrote:
> > On Tue, 2013-05-28 at 20:30 +0200, Florian Weimer wrote:
> > > On 05/28/2013 08:09 PM, Václav Zeman wrote:
> > > 
> > > > If the bottleneck is really in glibc, then you should probably ask them
> > > > to fix it. Could the mutex be changed rwlock instead?
> > > 
> > > rwlocks don't eliminate hardware contention, so I doubt they'd be a win 
> > > here.
> > 
> > Indeed.  Reader-writer locks guarantee the critical section, even the
> > readers, that they run mutually exclusive with writers.  So whatever you
> > do while holding the lock, the protected data won't change.  That
> > restricts what we can do, because we need to actively prevent writers
> > from doing things, which means making your read operation visible to
> > others (unless you can stop the writers in some other funny ways).
> > 
> > However, we only seem to need an atomic snapshot here AFAIU, in which
> > case we can do stuff like reading the data optimistically, verifying
> > that we read consistent data, and retrying if we didn't.
> 
> Please look at the mail I've posted in this threads, there are lots of ABI
> complexities involved and for many solutions it would require to change both
> glibc and gcc (the latter conditionally on glibc), which makes it a long
> term process.

I did read those emails (but didn't actually look at the dynamic loader
code).  What I was commenting on is that there are other ways to
synchronize in case we need an atomic snapshot (if it's such a case),
which are probably more efficient than a lock.  I wasn't at all
commenting on whether it would be simple to make such a change, or even
worth doing it for the potential performance gain.