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 [PATCH] splice support #2 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
-- strict thread matches above, loose matches on Subject: below --
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 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.