[PATCH 3/3] lib + libdw: Add and use a concurrent version of the dynamic-size hash table.

[Mark Wielaard]

On Sun, 2019-10-27 at 12:49 -0500, Jonathon Anderson wrote:
> In theory (if the system isn't overloaded) the threads should finish 
> their individual work at around the same time, so the amount of waiting 
> any one thread would do (should be) very short. Also, this is only once 
> per resize, which (shouldn't) happen very often anyway.
> 
> The other busy loops (in insert_helper) are also read-only with a 
> single concurrent store, so they (should) spin in cache until the 
> invalidation. Again, (should) be a short wait.
> 
> If it starts to be an issue we can add some exponential backoff, but I 
> haven't noticed any issues in general (and, a nanosleep itself is a 
> spin for suitably short durations, or so I've been told).

Yeah, it might even be easier to use a bit large initial (prime) size
for the hash to avoid the whole situation if it does look like it is a
problem in practice. I don't really expect it to. Just curious if there
was a different model. But sleeping might not be good either because it
might make it harder for the thread to start doing real work again if
it has to wake up the core it is running up again.


> Depends on your definition of significant, anything less than 10MB 
> would fall entirely below my radar, and the biggest thing I've tried 
> has 935 CUs. We also tend to close our Dwarfs regularly, I think the 
> maximum open we've used so far is one per thread.

Right, and that is a fairly large Dwarf which would take just 100K
extra memory. So normally it far less extra overhead.

> That said, I can also envision cases (say, a gdb on elfutils on a small 
> system) that might be prohibited (or at least annoyed) by this. I can 
> lower the overhead to 64 bytes easily (moving bits to the master 
> thread's stack), but that's the limit with this design.

Although I would like to see that if you have time, I am not that
concerned. And I think the pthread_key limit issue is more important to
resolve.

Thanks,

Mark