On Wed, May 19, 2010 at 02:00:51AM +1000, Nick Piggin wrote: > On Tue, May 18, 2010 at 10:56:24AM -0500, Christoph Lameter wrote: > > On Wed, 19 May 2010, Nick Piggin wrote: > > > > > What would be needed is to have filesystem maintainers go through and > > > enable it on a case by case basis. It's trivial for tmpfs/ramfs type > > > filesystems and I have a patch for those, but I never posted it on.yet. > > > Even basic buffer head filesystems IIRC get a little more complex -- > > > but we may get some milage just out of invalidating the existing > > > pagecache rather than getting fancy and trying to move buffers over > > > to the new page. > > > > There is a "migration" address space operation for moving pages. Page > > migration requires that in order to be able to move dirty pages. Can > > splice use that? > > Hmm yes I didn't think of that, it probably could. It's not the only requirement, of course, just that it could potentially reuse some of the code. The big difference is that the source page is already dirty, and the destination page might not exist, might exist and be partially uptodate, not have blocks allocated, might be past i_size, fully uptodate, etc. So it's more than a matter of just a simple copy to another page and taking over exactly the same filesystem state as the old page. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>