[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.