Re: [Xen-devel] [PATCHv7 2/3] gnttab: refactor locking for scalability

2015-05-05 Thread Jan Beulich
>>> On 30.04.15 at 15:28, wrote: >>> On 30.04.15 at 15:28, wrote: > This patch refactors grant table locking. It splits the previous > single spinlock per grant table into multiple locks. The heavily > modified components of the grant table (the maptrack state and the > active entries) are now pr

Re: [Xen-devel] [PATCHv7 2/3] gnttab: refactor locking for scalability

2015-05-01 Thread Tim Deegan
At 19:03 +0100 on 01 May (1430506982), David Vrabel wrote: > On 30/04/15 15:34, Tim Deegan wrote: > > > > OK, so here we hold rd->grant_table->lock and act->lock (which is in > > the rd table) and are going to acquire lgt->maptrack_lock in mapcount(). > > > > That means we can't ever have a path

Re: [Xen-devel] [PATCHv7 2/3] gnttab: refactor locking for scalability

2015-05-01 Thread David Vrabel
On 30/04/15 15:34, Tim Deegan wrote: > > OK, so here we hold rd->grant_table->lock and act->lock (which is in > the rd table) and are going to acquire lgt->maptrack_lock in mapcount(). > > That means we can't ever have a path holding domA's maptrack lock that > acquires domB's gt lock or one of d

Re: [Xen-devel] [PATCHv7 2/3] gnttab: refactor locking for scalability

2015-04-30 Thread Tim Deegan
At 14:28 +0100 on 30 Apr (1430404124), David Vrabel wrote: > +/* > + * N.B.: while taking the left side maptrack spinlock prevents > + * any mapping changes, the right side active entries could be > + * changing while we are counting. IIRC, the lX/rX variables are local/remote rat