From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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>,
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: Unexpected splice "always copy" behavior observed
Date: Tue, 18 May 2010 11:34:40 -0400 [thread overview]
Message-ID: <20100518153440.GB7748@Krystal> (raw)
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'll start with a disclaimer that I only recently improved my splice
understanding, so AFAIU:
* 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 ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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>,
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: Unexpected splice "always copy" behavior observed
Date: Tue, 18 May 2010 11:34:40 -0400 [thread overview]
Message-ID: <20100518153440.GB7748@Krystal> (raw)
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'll start with a disclaimer that I only recently improved my splice
understanding, so AFAIU:
* 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 ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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>
next reply other threads:[~2010-05-18 15:34 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-18 15:34 Mathieu Desnoyers [this message]
2010-05-18 15:34 ` Unexpected splice "always copy" behavior observed Mathieu Desnoyers
2010-05-18 15:51 ` Nick Piggin
2010-05-18 15:51 ` Nick Piggin
2010-05-18 15:56 ` Christoph Lameter
2010-05-18 15:56 ` Christoph Lameter
2010-05-18 16:00 ` Nick Piggin
2010-05-18 16:00 ` Nick Piggin
2010-05-18 16:13 ` Nick Piggin
2010-05-18 16:13 ` Nick Piggin
2010-05-18 15:53 ` Steven Rostedt
2010-05-18 15:53 ` Steven Rostedt
2010-05-18 16:10 ` Steven Rostedt
2010-05-18 16:10 ` Steven Rostedt
2010-05-18 16:25 ` Linus Torvalds
2010-05-18 16:25 ` Linus Torvalds
2010-05-19 6:31 ` Nick Piggin
2010-05-19 6:31 ` Nick Piggin
2010-05-19 14:39 ` Linus Torvalds
2010-05-19 14:39 ` Linus Torvalds
2010-05-19 14:56 ` Steven Rostedt
2010-05-19 14:56 ` Steven Rostedt
2010-05-19 14:59 ` Linus Torvalds
2010-05-19 14:59 ` Linus Torvalds
2010-05-19 15:12 ` Steven Rostedt
2010-05-19 15:12 ` Steven Rostedt
2010-05-19 15:51 ` Mathieu Desnoyers
2010-05-19 15:51 ` Mathieu Desnoyers
2010-05-19 15:33 ` Miklos Szeredi
2010-05-19 15:33 ` Miklos Szeredi
2010-05-19 15:45 ` Steven Rostedt
2010-05-19 15:45 ` Steven Rostedt
2010-05-19 15:55 ` Nick Piggin
2010-05-19 15:55 ` Nick Piggin
2010-05-19 16:01 ` Mathieu Desnoyers
2010-05-19 16:01 ` Mathieu Desnoyers
2010-05-19 16:36 ` Steven Rostedt
2010-05-19 16:36 ` Steven Rostedt
2010-05-19 15:57 ` Mathieu Desnoyers
2010-05-19 15:57 ` Mathieu Desnoyers
2010-05-19 16:27 ` Nick Piggin
2010-05-19 16:27 ` Nick Piggin
2010-05-19 19:14 ` Mathieu Desnoyers
2010-05-19 19:14 ` Mathieu Desnoyers
2010-05-19 19:31 ` Linus Torvalds
2010-05-19 19:31 ` Linus Torvalds
2010-05-19 21:49 ` Mathieu Desnoyers
2010-05-19 21:49 ` Mathieu Desnoyers
2010-05-20 0:04 ` Linus Torvalds
2010-05-20 0:04 ` Linus Torvalds
2010-05-20 1:56 ` Mathieu Desnoyers
2010-05-20 1:56 ` Mathieu Desnoyers
2010-05-20 14:18 ` Linus Torvalds
2010-05-20 14:18 ` Linus Torvalds
2010-05-20 14:18 ` Linus Torvalds
2010-05-19 20:59 ` Rick Sherm
2010-05-19 20:59 ` Rick Sherm
2010-05-19 15:17 ` Nick Piggin
2010-05-19 15:17 ` Nick Piggin
2010-05-19 15:30 ` Linus Torvalds
2010-05-19 15:30 ` Linus Torvalds
2010-05-19 15:44 ` Nick Piggin
2010-05-19 15:44 ` Nick Piggin
2010-05-19 15:28 ` Miklos Szeredi
2010-05-19 15:28 ` Miklos Szeredi
2010-05-19 15:32 ` Linus Torvalds
2010-05-19 15:32 ` Linus Torvalds
2010-05-19 15:56 ` Miklos Szeredi
2010-05-19 15:56 ` Miklos Szeredi
2010-05-19 16:01 ` Linus Torvalds
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=20100518153440.GB7748@Krystal \
--to=mathieu.desnoyers@efficios.com \
--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=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.