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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.11.13 at 14:58, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 12/11/2013 13:42, "Keir Fraser" <keir.xen@xxxxxxxxx> 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.

Sounds nice - are you going to spend time on implementing this then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel