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: [RFC] improving spinning in adaptive mutexes


On 2/28/2013 10:57 AM, Torvald Riegel wrote:
> === Issues in the current implementation
>
> --- Inefficient spinning
>
> 1) No spinning using loads but with just trylock()
> - trylock() doesn't first check whether the lock is free using a load,
> which can be beneficial in the case of uncontended locks (based on
> related measurements I did a few years ago; I don't have current numbers)
> - If the atomic instruction in trylock() puts the lock's cache line into
> exclusive state right away, we cause cache misses with the spinning.

On the current Tilera microarchitectures, test-and-test-and-set turns out to be a pessimization.  The problem is that the initial "test" is a load, which is sent over the on-chip memory network and results in returning a copy of the cache line from the home cache.  Then, when some core succeeds at taking the lock, the modification to the cache line at the home requires the home to invalidate all the copied cache lines, which involves a bunch of memory network traffic when multiple cores are trying to acquire the lock, as well as delay at the cache line's home as it waits for the invalidates to all be acknowledged by the other cores' caches.  As you scale up to dozens of cores, this effect starts to dominate.

By contrast, the atomic operations work directly at the home cache of the cache line, so no cache line copying and invalidating is required as cores try to acquire the lock.  Instead you just have each core sending short atomic operation requests over the memory network and getting back short atomic result responses, so along with appropriate backoff, things scale up much better.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com


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