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

[Matt Wilson <msw@xxxxxxxxx>]

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?

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