mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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