From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 2/2] xfs: hole-punch retaining cache beyond Date: Tue, 15 May 2012 02:58:54 -0400 Message-ID: <20120515065854.GB7373@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Dave Chinner , Ben Myers , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org To: Hugh Dickins Return-path: Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net ([173.166.109.252]:36792 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752574Ab2EOG64 (ORCPT ); Tue, 15 May 2012 02:58:56 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.