From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754105Ab0ERQNO (ORCPT <rfc822;w@1wt.eu>);
	Tue, 18 May 2010 12:13:14 -0400
Received: from cantor2.suse.de ([195.135.220.15]:48481 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752180Ab0ERQNM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 18 May 2010 12:13:12 -0400
Date: Wed, 19 May 2010 02:13:08 +1000
From: Nick Piggin <npiggin@suse.de>
To: Christoph Lameter <cl@linux.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
       Peter Zijlstra <peterz@infradead.org>,
       Steven Rostedt <rostedt@goodmis.org>,
       Frederic Weisbecker <fweisbec@gmail.com>,
       Pierre Tardy <tardyp@gmail.com>, Ingo Molnar <mingo@elte.hu>,
       Arnaldo Carvalho de Melo <acme@redhat.com>,
       Tom Zanussi <tzanussi@gmail.com>, Paul Mackerras <paulus@samba.org>,
       linux-kernel@vger.kernel.org, arjan@infradead.org,
       ziga.mahkovec@gmail.com, davem <davem@davemloft.net>,
       linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
       KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
       Tejun Heo <tj@kernel.org>, Jens Axboe <jens.axboe@oracle.com>,
       Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Unexpected splice "always copy" behavior observed
Message-ID: <20100518161308.GL2516@laptop>
References: <20100518153440.GB7748@Krystal>
 <20100518155135.GJ2516@laptop>
 <alpine.DEB.2.00.1005181055260.16649@router.home>
 <20100518160051.GK2516@laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100518160051.GK2516@laptop>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.