linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.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>,
	Christoph Lameter <cl@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Jens Axboe <jens.axboe@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: Unexpected splice "always copy" behavior observed
Date: Tue, 18 May 2010 11:53:13 -0400	[thread overview]
Message-ID: <1274197993.26328.755.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20100518153440.GB7748@Krystal>

Hehe, I just notice this this morning too, while investigating.


On Tue, 2010-05-18 at 11:34 -0400, Mathieu Desnoyers wrote:
> Hi,
> 
> I'm currently digging into the splice code to figure out why it's always in copy
> mode even though I specified the SPLICE_F_MOVE flag and released the page
> references from the LTTng ring buffer. I'm splicing to a pipe and then from the
> pipe to an ext3 filesystem (2.6.33.4 kernel). I've got the feeling I'm missing
> something and I don't like that.
> 
> My simple test case is to add a printk around the splice copy:
> 
> fs/splice.c: pipe_to_file()
>        if (buf->page != page) {
>                 /*
>                  * Careful, ->map() uses KM_USER0!
>                  */
>                 char *src = buf->ops->map(pipe, buf, 1);
>                 char *dst = kmap_atomic(page, KM_USER1);
> 
>                 printk(KERN_WARNING "SPLICE COPY!!!\n");
>                 memcpy(dst + offset, src + buf->offset, this_len);
>                 flush_dcache_page(page);
>                 kunmap_atomic(dst, KM_USER1);
>                 buf->ops->unmap(pipe, buf, src);

I used trace_printk() since it is not as invasive.

>         }
> 
> I'll start with a disclaimer that I only recently improved my splice
> understanding, so AFAIU:

Same here ;-)

> 
> * pipe_to_file() allocates a struct page *page on its stack.
> 
> * It is passed, uninitialized, to
> 
>         ret = pagecache_write_begin(file, mapping, sd->pos, this_len,
>                                 AOP_FLAG_UNINTERRUPTIBLE, &page, &fsdata);
> 
>     that looks already odd to me, as I would expect pipe_to_file to populate
>     this page pointer with buf->page initially if the proper conditions are met.
> 
> * Looking at the ext2 and ext3 write_begin code, neither are using the pagep
>   parameter:
> 
>   ext2:
> 
> static int
> ext2_write_begin(struct file *file, struct address_space *mapping,
>                 loff_t pos, unsigned len, unsigned flags,
>                 struct page **pagep, void **fsdata)
> {
>         *pagep = NULL;
>         return __ext2_write_begin(file, mapping, pos, len, flags, pagep,fsdata);
> }
> 
> 
>   ext3:
> 
> static int ext3_write_begin(struct file *file, struct address_space *mapping,
>                                 loff_t pos, unsigned len, unsigned flags,
>                                 struct page **pagep, void **fsdata)
> {
>         struct page *page;
>         ....
> 
> retry:
>         page = grab_cache_page_write_begin(mapping, index, flags);
>         if (!page)
>                 return -ENOMEM;
>         *pagep = page;
> 
> * So, considering the test to check if the page content must be copied:
> 
>        if (buf->page != page) {
> 
>   how is it ever possible that buf->page == page ?

I'm currently looking at the network code to see if it is better.

-- Steve


--
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>

  parent reply	other threads:[~2010-05-18 15:53 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 15:34 Mathieu Desnoyers
2010-05-18 15:51 ` Nick Piggin
2010-05-18 15:56   ` Christoph Lameter
2010-05-18 16:00     ` Nick Piggin
2010-05-18 16:13       ` Nick Piggin
2010-05-18 15:53 ` Steven Rostedt [this message]
2010-05-18 16:10   ` Steven Rostedt
2010-05-18 16:25     ` Linus Torvalds
2010-05-19  6:31       ` Nick Piggin
2010-05-19 14:39         ` Linus Torvalds
2010-05-19 14:56           ` Steven Rostedt
2010-05-19 14:59             ` Linus Torvalds
2010-05-19 15:12               ` Steven Rostedt
2010-05-19 15:51                 ` Mathieu Desnoyers
2010-05-19 15:33               ` Miklos Szeredi
2010-05-19 15:45                 ` Steven Rostedt
2010-05-19 15:55                   ` Nick Piggin
2010-05-19 16:01                     ` Mathieu Desnoyers
2010-05-19 16:36                     ` Steven Rostedt
2010-05-19 15:57                   ` Mathieu Desnoyers
2010-05-19 16:27                     ` Nick Piggin
2010-05-19 19:14                       ` Mathieu Desnoyers
2010-05-19 19:31                         ` Linus Torvalds
2010-05-19 21:49                           ` Mathieu Desnoyers
2010-05-20  0:04                             ` Linus Torvalds
2010-05-20  1:56                               ` Mathieu Desnoyers
2010-05-20 14:18                                 ` Linus Torvalds
2010-05-19 20:59               ` Rick Sherm
2010-05-19 15:17           ` Nick Piggin
2010-05-19 15:30             ` Linus Torvalds
2010-05-19 15:44               ` Nick Piggin
2010-05-19 15:28           ` Miklos Szeredi
2010-05-19 15:32             ` Linus Torvalds
2010-05-19 15:56               ` Miklos Szeredi
2010-05-19 16:01                 ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1274197993.26328.755.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=cl@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=fweisbec@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tardyp@gmail.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tzanussi@gmail.com \
    --cc=ziga.mahkovec@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox