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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 12/11/2013 14:11, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

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

Yes I'll look into it. Amazon's benchmarking of grant-table throughput will
be a good testbed for performance of a different lock implementation.

 -- Keir

> Jan
> 



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