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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
