xfs
[Top] [All Lists]

Re: [PATCH 4/9] [PATCH 4/9] xfs: dont serialise direct IO reads on page

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 4/9] [PATCH 4/9] xfs: dont serialise direct IO reads on page cache
From: Greg KH <greg@xxxxxxxxx>
Date: Tue, 22 Nov 2011 13:35:44 -0800
Cc: stable@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, Dave Chinner <dchinner@xxxxxxxxxx>, Alex Elder <aelder@xxxxxxx>
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=IFY1pyvDtDtyqKpOWhALGcmLoWo=; b=YjP/u+jrSGqCXyzVsa5HAel6C40x 2CIwyLlXgEyGVHT/3NkzNwh/zCXHHi6ZezrkjQik/Vd1vGCNrwpPMxEXtZGAx5u8 jg7MEBt7cBWC1o4BQ9Pb98VtNAAsBpYr3mh/VSq1an0YJsLk8ugroz+eMHxPbn2Z 1p2Ndg5ju+2TtIo=
In-reply-to: <20111122213425.GA29127@xxxxxxxxx>
References: <20111119181336.964593075@xxxxxxxxxxxxxxxxxxxxxx> <20111119181544.111984285@xxxxxxxxxxxxxxxxxxxxxx> <20111122213425.GA29127@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Nov 22, 2011 at 01:34:25PM -0800, Greg KH wrote:
> On Sat, Nov 19, 2011 at 01:13:40PM -0500, Christoph Hellwig wrote:
> > There is no need to grab the i_mutex of the IO lock in exclusive
> > mode if we don't need to invalidate the page cache. Taking these
> > locks on every direct IO effective serialises them as taking the IO
> > lock in exclusive mode has to wait for all shared holders to drop
> > the lock. That only happens when IO is complete, so effective it
> > prevents dispatch of concurrent direct IO reads to the same inode.
> > 
> > Fix this by taking the IO lock shared to check the page cache state,
> > and only then drop it and take the IO lock exclusively if there is
> > work to be done. Hence for the normal direct IO case, no exclusive
> > locking will occur.
> > 
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > Tested-by: Joern Engel <joern@xxxxxxxxx>
> > Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> > Signed-off-by: Alex Elder <aelder@xxxxxxx>
> 
> What is the git commit id that matches this patch in Linus's tree?

Nevermind, I found it, 0c38a2512df272b14ef4238b476a2e4f70da1479, right?

Next time, please include the git commit id of the patch in Linus's tree
so I don't have to dig it out like I did for this series.

thanks,

greg k-h

<Prev in Thread] Current Thread [Next in Thread>