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

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Tue, Nov 12, 2013 at 02:24:50PM +0000, Keir Fraser wrote:
> 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.

ping?
> 
>  -- Keir
> 
> > Jan
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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