From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: [PATCH] splice support #2
Date: Thu, 30 Mar 2006 12:24:19 +0200 [thread overview]
Message-ID: <20060330102419.GU13476@suse.de> (raw)
In-Reply-To: <20060330021644.7f7c5282.akpm@osdl.org>
On Thu, Mar 30 2006, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > Hi,
> >
> > This patch should resolve all issues mentioned so far. I'd still like to
> > implement the page moving, but that should just be a separate patch.
> > After this round of patching, I thought I'd toss a fresh version out
> > there for all to look at.
> >
> > Signed-off-by: Jens Axboe <axboe@suse.de>
> >
> > ...
> >
> > --- a/arch/ia64/kernel/entry.S
> > +++ b/arch/ia64/kernel/entry.S
> > @@ -1605,5 +1605,6 @@ sys_call_table:
> > data8 sys_ni_syscall // reserved for pselect
> > data8 sys_ni_syscall // 1295 reserved for ppoll
> > data8 sys_unshare
> > + date8 sys_splice
>
> typo
Oops, fixed.
> > +static void *page_cache_pipe_buf_map(struct file *file,
> > + struct pipe_inode_info *info,
> > + struct pipe_buffer *buf)
> > +{
> > + struct page *page = buf->page;
> > +
> > + lock_page(page);
> > +
> > + if (!PageUptodate(page)) {
>
> || page->mapping == NULL
Fixed
> > + struct page *pages[PIPE_BUFFERS];
> > + struct page *page;
> > + pgoff_t index, pidx;
> > + int i;
> > +
> > + index = in->f_pos >> PAGE_CACHE_SHIFT;
> > + offset = in->f_pos & ~PAGE_CACHE_MASK;
> > + nr_pages = (len + offset + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
> > +
> > + if (nr_pages > PIPE_BUFFERS)
> > + nr_pages = PIPE_BUFFERS;
> > +
> > + /*
> > + * initiate read-ahead on this page range
> > + */
> > + do_page_cache_readahead(mapping, in, index, nr_pages);
> > +
> > + /*
> > + * Get as many pages from the page cache as possible..
> > + * Start IO on the page cache entries we create (we
> > + * can assume that any pre-existing ones we find have
> > + * already had IO started on them).
> > + */
> > + i = find_get_pages(mapping, index, nr_pages, pages);
> > +
> > + /*
> > + * common case - we found all pages and they are contiguous,
> > + * kick them off
> > + */
> > + if (i && (pages[i - 1]->index == index + i - 1))
> > + goto splice_them;
> > +
> > + memset(&pages[i], 0, (nr_pages - i) * sizeof(struct page *));
> > +
> > + /*
> > + * find_get_pages() may not return consecutive pages, so loop
> > + * over the array moving pages and filling the rest, if need be.
> > + */
> > + for (i = 0, pidx = index; i < nr_pages; pidx++, i++) {
> > + if (!pages[i]) {
> > + int error;
> > +fill_page:
> > + /*
> > + * no page there, look one up / create it
> > + */
> > + page = find_or_create_page(mapping, pidx,
> > + mapping_gfp_mask(mapping));
> > + if (!page)
> > + break;
> > +
> > + if (PageUptodate(page))
> > + unlock_page(page);
> > + else {
> > + error = mapping->a_ops->readpage(in, page);
> > +
> > + if (unlikely(error)) {
> > + page_cache_release(page);
> > + break;
> > + }
> > + }
> > + pages[i] = page;
> > + } else if (pages[i]->index != pidx) {
> > + page = pages[i];
> > + /*
> > + * page isn't in the right spot, move it and jump
> > + * back to filling this one. we know that ->index
> > + * is larger than pidx
> > + */
> > + pages[i + page->index - pidx] = page;
> > + pages[i] = NULL;
> > + goto fill_page;
> > + }
> > + }
> > +
> > + if (!i)
> > + return 0;
> > +
> > + /*
> > + * Now we splice them into the pipe..
> > + */
> > +splice_them:
> > + return move_to_pipe(pipe, pages, i, offset, len);
> > +}
>
> OK, and this returns the number of bytes transferred all the way up to
> userspace.
>
> And, like read(), if we hit an IO error or ENOMEM partway through we'll
> just return a short read which is indistinguishable from EOF.
>
> But if we do get an IO error, we'll detect it in page_cache_pipe_buf_map().
> Does the code still follow these read() return value semantics in that
> case?
Yes, see:
err = actor(info, buf, &sd);
if (err) {
if (!ret)
ret = err;
break;
}
so if we get -EIO from the actor, then we return bytes transferred _or_
-EIO in 0.
> argh, am all reviewed out, and infiniband isn't compiling. Will look later.
I don't blame you, you've been (as always) a huge help! Thanks a lot.
--
Jens Axboe
next prev parent reply other threads:[~2006-03-30 10:24 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-30 10:06 Jens Axboe
2006-03-30 10:16 ` Andrew Morton
2006-03-30 10:24 ` Jens Axboe [this message]
2006-03-30 11:16 ` Andrew Morton
2006-03-30 11:55 ` Jens Axboe
2006-03-30 12:30 ` Jens Axboe
2006-03-30 12:30 ` Jens Axboe
2006-03-30 19:19 ` Andrew Morton
2006-03-30 12:00 ` Ingo Molnar
2006-03-30 12:05 ` Jens Axboe
2006-03-30 12:10 ` Ingo Molnar
2006-03-30 12:16 ` Jens Axboe
2006-03-30 12:38 ` Ingo Molnar
2006-03-30 12:42 ` Jens Axboe
2006-03-30 12:42 ` Ingo Molnar
2006-03-30 13:02 ` Jens Axboe
2006-03-30 14:20 ` Christoph Hellwig
2006-03-30 17:02 ` Linus Torvalds
2006-03-30 17:17 ` Linus Torvalds
2006-03-31 20:38 ` Hua Zhong
2006-03-31 20:49 ` Linus Torvalds
2006-03-30 20:48 ` Jeff Garzik
2006-03-30 21:16 ` Linus Torvalds
2006-03-31 0:59 ` Nick Piggin
2006-03-31 2:43 ` Andrew Morton
2006-03-31 2:51 ` Andrew Morton
2006-03-31 3:20 ` Nick Piggin
2006-03-31 6:35 ` Christoph Hellwig
2006-03-31 7:09 ` Ingo Molnar
2006-04-02 22:33 ` Pavel Machek
2006-03-31 12:46 ` Bernd Petrovitsch
2006-03-31 9:56 ` Jens Axboe
2006-03-31 12:18 ` Ingo Molnar
2006-03-31 12:23 ` Jens Axboe
2006-03-31 12:26 ` Jens Axboe
2006-03-31 12:47 ` Ingo Molnar
2006-03-31 18:18 ` Jens Axboe
2006-03-31 12:27 ` Ingo Molnar
2006-03-31 0:03 linux
2006-03-31 6:06 tridge
2006-03-31 6:59 ` Antonio Vargas
2006-03-31 7:37 ` tridge
2006-03-31 9:57 ` Jens Axboe
2006-03-31 19:11 ` Linus Torvalds
2006-03-31 19:40 ` Jens Axboe
2006-04-04 17:16 ` Andy Lutomirski
2006-04-04 17:34 ` Jens Axboe
[not found] <5W2gv-Tp-19@gated-at.bofh.it>
[not found] ` <5W48C-3KW-17@gated-at.bofh.it>
[not found] ` <5W48D-3KW-21@gated-at.bofh.it>
[not found] ` <5W8OT-2ms-17@gated-at.bofh.it>
[not found] ` <5WcfS-7x9-23@gated-at.bofh.it>
[not found] ` <5WcIT-8nr-13@gated-at.bofh.it>
[not found] ` <5Wm5I-53z-7@gated-at.bofh.it>
[not found] ` <5XjoS-8t9-11@gated-at.bofh.it>
2006-04-03 12:39 ` Bodo Eggert
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=20060330102419.GU13476@suse.de \
--to=axboe@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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
Powered by JetHome