Re: Unexpected splice "always copy" behavior observed

[Nick Piggin <npiggin@suse.de>]

On Wed, May 19, 2010 at 07:39:11AM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 19 May 2010, Nick Piggin wrote:
> > 
> > We can possibly do an attempt to invalidate existing pagecache and
> > then try to install the new page.
> 
> Yes, but that's going to be rather hairier. We need to make sure that the 
> filesystem doesn't have some kind of dirty pointers to the old page etc. 
> Although I guess that should always show up in the page counters, so I 
> guess we can always handle the case of page_count() being 1 (only page 
> cache) and the page being unlocked.

Well I mean a full invalidate -- invalidate_mapping_pages -- so there is
literally no pagecache there at all.

Then we just need to ensure that the filesystem doesn't do anything
funny with the page in write_begin (I don't know, such as zero out holes
or something strange). I don't think any do except maybe for something
obscure like jffs2, but obviously it needs to be looked at.

Error handling may need to be looked at too, but shouldn't be much
issue I'd think.
 
Even so, it's all going to add branches and complexity to an important
fast path, so we'd want to see numbers.


> So I'd much rather just handle the "append to the end".
> 
> The real limitation is likely always going to be the fact that it has to 
> be page-aligned and a full page. For a lot of splice inputs, that simply 
> won't be the case, and you'll end up copying for alignment reasons anyway.

That's true.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>