xfs
[Top] [All Lists]

Re: [PATCH 2/2] xfs: hole-punch retaining cache beyond

To: Hugh Dickins <hughd@xxxxxxxxxx>
Subject: Re: [PATCH 2/2] xfs: hole-punch retaining cache beyond
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 15 May 2012 02:58:54 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx
In-reply-to: <alpine.LSU.2.00.1205131350150.1547@xxxxxxxxxxxx>
References: <alpine.LSU.2.00.1205131347120.1547@xxxxxxxxxxxx> <alpine.LSU.2.00.1205131350150.1547@xxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sun, May 13, 2012 at 01:51:18PM -0700, Hugh Dickins wrote:
> xfs has a very inefficient hole-punch implementation, invalidating all
> the cache beyond the hole (after flushing dirty back to disk, from which
> all must be read back if wanted again).  So if you punch a hole in a
> file mlock()ed into userspace, pages beyond the hole are inadvertently
> munlock()ed until they are touched again.
> 
> Is there a strong internal reason why that has to be so on xfs?
> Or is it just a relic from xfs supporting XFS_IOC_UNRESVSP long
> before Linux 2.6.16 provided truncate_inode_pages_range()?
> 
> If the latter, then this patch mostly fixes it, by passing the proper
> range to xfs_flushinval_pages().  But a little more should be done to
> get it just right: a partial page on either side of the hole is still
> written back to disk, invalidated and munlocked.

I think the original reason is that no range version of the macros
existed.  Giving the somewhat odd calling convention I'd prefer to
simplify deprecate the old wrappers and convert the callers to direct
calls of the VM functions on a 1 by 1 basis.

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