From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1040.oracle.com ([141.146.126.69]:28085 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753310AbdJSWoj (ORCPT ); Thu, 19 Oct 2017 18:44:39 -0400 Date: Thu, 19 Oct 2017 15:44:31 -0700 From: "Darrick J. Wong" Subject: Re: [PATCH for-4.14] xfs: fix AIM7 regression Message-ID: <20171019224431.GO4755@magnolia> References: <20171019074705.24827-1-hch@lst.de> <20171019113848.GA8911@bfoster.bfoster> <20171019131407.GA20645@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171019131407.GA20645@lst.de> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Christoph Hellwig Cc: Brian Foster , linux-xfs@vger.kernel.org On Thu, Oct 19, 2017 at 03:14:07PM +0200, Christoph Hellwig wrote: > On Thu, Oct 19, 2017 at 07:38:48AM -0400, Brian Foster wrote: > > On Thu, Oct 19, 2017 at 09:47:05AM +0200, Christoph Hellwig wrote: > > > Apparently our current rwsem code doesn't like doing the trylock, then > > > lock for real scheme. So change our read/write methods to just do the > > > trylock for the RWF_NOWAIT case. This fixes a ~25% regression in > > > AIM7. > > > > > > > The code looks fine, but this seems really strange. If the trylock > > fails, then wouldn't the blocking lock have slept anyways if done > > initially? Is there any more background info available on this, or > > perhaps a theory on why there is such a significant regression..? > > No, unfortunately I don't have a theory, but I agree it is odd > behavior in the rwsem code. I want to know a little more about why there's a performance hit in the down_read_trylock -> down_read case. Are we getting penalized for that? Is it some weird interaction with lockdep? --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html