Re: [RFC PATCH 2/2] gnttab: refactor locking for better scalability

[Keir Fraser <keir.xen@gmail.com>]

On 12/11/2013 13:42, "Keir Fraser" <keir.xen@gmail.com> wrote:

>> And indeed I think we should be making our rwlocks fair for writers
>> before pushing in the change here; I've been meaning to get to this
>> for a while, but other stuff continues to require attention. I'm also
>> of the opinion that we should switch to ticket spinlocks.
> 
> Would queuing spinlocks (e.g. MCS locks) be even more preferable? Two atomic
> ops (cmpxchg) per critical region in the uncontended case. Each CPU spins on
> its own location so there's no cacheline carnage in the highly contended
> case (a problem with simple ticket spinlocks). And it builds on cmpxchg so
> the spinlock implementation has no arch-specific component (apart from
> cmpxchg, which we already have).
> 
> I have a queue-based rwlock design too, does require a spinlock lock/unlock
> per rwlock op though (i.e., 4 atomic ops per critical region in the
> uncontended case).

Actually MCS has a multi-reader extension we could use, or there is another
alternative by Krieger et al. My own design was intended to build on pthread
primitives and wouldn't be as good as the existing solutions in the
literature for purely spinning waiters.

 -- Keir