Re: TSX lock elision for glibc v2

[OndÅej BÃlka <neleai at seznam dot cz>]

On Tue, Jan 22, 2013 at 06:49:28PM +0100, Andi Kleen wrote:
> On Tue, Jan 22, 2013 at 05:45:11PM +0100, Torvald Riegel wrote:
> > On Sat, 2013-01-19 at 00:38 +0100, Andi Kleen wrote:
> > > Sorry the question doesn't make any sense to me and I cannot
> > > answer it. If you think the read write lock elision should
> > > do something different please present a code example.
> > 
> > No, the implementation you posted makes sense; I had just asked whether
> > you had considered certain other lock elision uses too, and it seems as
> > you haven't.  Which is fine -- I think we have enough other things to
> > discuss.
> 
> I considered malloc and condition variables in the past.
> 
> But it's unclear if malloc would really benefit.  The new per thread
> pool malloc seems to do reasonably well. 
>
In malloc as I described in previous thread locking seem bottleneck.
Unless with lock elision it would take 10 cycles or so then implementations that 
avoid locks/atomic are better.

For overall malloc performance hot path are single threaded 
applications. On my computer profiling shown that around 99% of
allocations are from main thread and remaining 1% is caused 
only by java.

 
> Condition variables likely would benefit and I have some test cases that would
> benefit.  But it wouldn't help always, only when not blocking.
> 
> I also considered stdio at some point, but it is unlikely to help there.

Only use of locks in stdio is writing log files. Otherwise locking should be done
is user level (Most time by having only one thread that reads/writes.)
What could help for writing are thread local buffers but I do not know
what to do in reading.
> 
> But first have to get the basics going, before thinking about those.
> than glibc.  Baby steps are important.
> 
> In any case user applications tend to have far worse locking problems
> than glibc.
> 
> -Andi

-- 

Computer room being moved.  Our systems are down for the weekend.