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: [PATCHv2] powerpc: Spinlock optimization and cleanup


On Wed, 2015-10-07 at 14:00 -0500, Paul E. Murphy wrote:
> 
> On 10/01/2015 02:27 PM, Torvald Riegel wrote:
> > On Wed, 2015-09-30 at 11:28 -0500, Paul E. Murphy wrote:
> >> Changes from V1:
> >>
> >> * Use C macro for atomic_store_release as suggested in
> >> comments.
> >>
> >> * Run benchmarks to quantize the performance changes and
> >> note in commit message.
> >>
> >> ---8<---
> >> This patch optimizes powerpc spinlock implementation by:
> >>
> >> * Current algorithm spin over a lwzx, but only after issuing a lwarx.
> >>   first.  The optimization for such case is to avoid the first lwarx
> >>   in contention case (which is much more costly than normal loads).
> >>
> >> * Use the correct EH hint bit on the larx for supported ISA.  For lock
> >>   acquisition, the thread that acquired the lock with a successful stcx
> >>   do not want to give away the write ownership on the cacheline.  The
> >>   idea is to make the load reservation "sticky" about retaining write
> >>   authority to the line.  That way, the store that must inevitably come
> >>   to release the lock can succeed quickly and not contend with other
> >>   threads issuing lwarx.  If another thread does a store to the line
> >>   (false sharing), the winning thread must give up write authority to
> >>   The proper value of EH for the larx for a lock acquisition is 1.
> >>
> >> * Increase contented lock performance by up to 40%, and no measurable
> >>   impact on uncontended locks on P8.
> > 
> > Could you add the tests you used to the glibc microbenchmarks (or
> > whatever works best for them)?  We do want to be able to track
> > performance, and having benchmarks is the first step towards that.
> 
> Would you object to that being a separate patch?

No.

> As I sketch out the work to integrate it into our benchtest, it seems
> like it could be trivially extended to mutexes aswell.

Agreed.


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