From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malcolm Crossley Subject: Re: [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock Date: Wed, 18 Nov 2015 11:50:50 +0000 Message-ID: <564C661A.9030209@citrix.com> References: <1446573502-8019-1-git-send-email-malcolm.crossley@citrix.com> <1446573502-8019-2-git-send-email-malcolm.crossley@citrix.com> <564B6C1A02000078000B603C@prv-mh.provo.novell.com> <564B6453.6050008@citrix.com> <564B746802000078000B60E1@prv-mh.provo.novell.com> <564B69A8.6050609@citrix.com> <1447842971.23626.30.camel@citrix.com> <564C670E02000078000B637B@prv-mh.provo.novell.com> <564C5FA8.8020808@citrix.com> <564C71EF02000078000B63D2@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Zz1GK-0001QH-SB for xen-devel@lists.xenproject.org; Wed, 18 Nov 2015 11:50:56 +0000 In-Reply-To: <564C71EF02000078000B63D2@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , keir@xen.org, stefano.stabellini@citrix.com, Ian Campbell , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 18/11/15 11:41, Jan Beulich wrote: >>>> On 18.11.15 at 12:23, wrote: >> On 18/11/15 10:54, Jan Beulich wrote: >>> That's not how I understood it, the rwlock isn't per-pCPU (at least not >>> in what this patch does - it remains a per-domain one). The per-pCPU >>> object is a pointer to an rwlock, which gets made point to whatever >>> domain's rwlock the pCPU wants to own. >> >> This description is correct but it's important to note that the rwlock >> is only used by the writers and could be effectively replaced with a >> spinlock. > > While such replacement may indeed be possible (whether desirable > is another question), I'm pretty sure I saw readers taking the read > lock on the slow path. > You are right, the core code currently relies upon rw locks. Conceptually it may not need to but that's a different question as you state. Sorry for that mistake. Maybe it would be clearer if we created a percpu_rwlock_t which is really a rwlock_t. This would prevent accidental usage of the underlying rwlock_t by new grant table code. Malcolm > Jan >