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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Jun 20, 2014 5:18 PM, Matt Wilson <msw@xxxxxxxxx> wrote:
>
> On Fri, Jun 20, 2014 at 04:54:15PM -0400, Konrad Rzeszutek Wilk wrote: 
> > 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? 
>
> Ooph. Sorry, I've not had any time to work on this since posting last 
> year. Has there been any other discussion about a new locking 
> primitive? 
>

My recollection from this thread is that we are waiting for Keir for MCS + 
multireader extension patches.

Especially as I was reviewing the proposed qspinlocks (MCS variant for Linux) 
and everything is fresh in my mind.

> Konrad, are you looking for someone to rebase and break up the 
> proposed patch as is? 
>
> --msw 
>
> _______________________________________________ 
> 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