From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Miklos Szeredi <miklos@szeredi.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
peterz@infradead.org, fweisbec@gmail.com, tardyp@gmail.com,
mingo@elte.hu, acme@redhat.com, tzanussi@gmail.com,
paulus@samba.org, linux-kernel@vger.kernel.org,
arjan@infradead.org, ziga.mahkovec@gmail.com,
davem@davemloft.net, linux-mm@kvack.org,
akpm@linux-foundation.org, kosaki.motohiro@jp.fujitsu.com,
cl@linux-foundation.org, tj@kernel.org, jens.axboe@oracle.com
Subject: Re: Unexpected splice "always copy" behavior observed
Date: Wed, 19 May 2010 12:01:35 -0400 [thread overview]
Message-ID: <20100519160135.GC2039@Krystal> (raw)
In-Reply-To: <20100519155505.GD2516@laptop>
* Nick Piggin (npiggin@suse.de) wrote:
> On Wed, May 19, 2010 at 11:45:42AM -0400, Steven Rostedt wrote:
> > On Wed, 2010-05-19 at 17:33 +0200, Miklos Szeredi wrote:
> > > On Wed, 19 May 2010, Linus Torvalds wrote:
> > > > Btw, since you apparently have a real case - is the "splice to file"
> > > > always just an append? IOW, if I'm not right in assuming that the only
> > > > sane thing people would reasonable care about is "append to a file", then
> > > > holler now.
> > >
> > > Virtual machines might reasonably need this for splicing to a disk
> > > image.
> >
> > This comes down to balancing speed and complexity. Perhaps a copy is
> > fine in this case.
> >
> > I'm concerned about high speed tracing, where we are always just taking
> > pages from the trace ring buffer and appending them to a file or sending
> > them off to the network. The slower this is, the more likely you will
> > lose events.
> >
> > If the "move only on append to file" is easy to implement, I would
> > really like to see that happen. The speed of splicing a disk image for a
> > virtual machine only impacts the patience of the user. The speed of
> > splicing tracing output, impacts how much you can trace without losing
> > events.
>
> It's not "easy" to implement :) What's your ring buffer look like?
> Is it a normal user address which the kernel does copy_to_user()ish
> things into? Or a mmapped special driver?
>
> If the latter, it get's even harder again. But either way if the
> source pages just have to be regenerated anyway (eg. via page fault
> on next access), then it might not even be worthwhile to do the
> splice move.
Steven and I use pages to which we write directly by using the page address from
the linear memory mapping returned by page_address(). These pages have no other
mapping. They are moved to the pipe, and then from the pipe to a file (or to the
network). It's possibly the simplest scenario you could think of for splice().
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 prev parent reply other threads:[~2010-05-19 16:01 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-18 15:34 Unexpected splice "always copy" behavior observed 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
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 [this message]
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=20100519160135.GC2039@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=miklos@szeredi.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).