From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: [PATCH][RFC] splice support
Date: Thu, 30 Mar 2006 11:15:24 +0200 [thread overview]
Message-ID: <20060330091523.GQ13476@suse.de> (raw)
In-Reply-To: <20060330085134.GP13476@suse.de>
On Thu, Mar 30 2006, Jens Axboe wrote:
> On Thu, Mar 30 2006, Andrew Morton wrote:
> > Jens Axboe <axboe@suse.de> wrote:
> > >
> > > > find_get_pages() does "find me the next N pages above `index' which are
> > > > presently in pagecache'. So it can return an array of page*'s which do not
> > > > represent contiguous pages in the file - there can be holes in there.
> > > >
> > > > IOW: pages[n]->index !necessarily= pages[n+1]->index-1
> > > >
> > > > Maybe the code handles that by making sure that all the pages in the range
> > > > are already in pagecache - I didn't check. But that would take some heroic
> > > > locking.
> > >
> > > It doesn't, I'm assuming that find_get_pages() returns consequtive pages
> > > atm. Would seem like the sane interface :-)
> >
> > Yeah, sorry. It's a "gather what's presently there" thing. For writeback.
> >
> > Nick has some gang-lookup-slots code. So instead of populating an array of
> > page*'s you can populate an array of (effectively) page**'s. Then one
> > could walk that. All while holding ->tree_lock. This doesn't help ;)
> >
> > Or you could walk the pages[] array until you hit an ->index which doesn't
> > match and then toss the rest away. That's a bit of extra work, but in the
> > common case all the pages will be good. Perhaps.
> >
> > > We continue doing find_or_create_page() on the remaining, but using 'i'
> > > as the 'index' addition. So if we had non-conseq pages, we'd be screwed.
> >
> > Yup.
> >
> > Probably the simplest for now is an open-coded find_get_page() loop. Later
> > on we should optimise that into a find_get_contig_pages() which only takes
> > tree_lock a single time.
> >
> > Doing it with a new radix_tree_gang_lookup_contig_name_me_longer() would be
> > relatively straightforward too. It would bale out as soon as it hit a
> > not-present slot.
>
> I'll go for the simple approach right now, going over the returned
> find_get_pages() array and moving pages around and filling holes doesn't
> sound too alluring. Thanks!
Actually it isn't so bad, how does this look?
diff --git a/fs/splice.c b/fs/splice.c
index 6327a7c..e7bb2ed 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -161,7 +161,8 @@ static int __generic_file_splice_read(st
struct address_space *mapping = in->f_mapping;
unsigned int offset, nr_pages;
struct page *pages[PIPE_BUFFERS];
- pgoff_t index;
+ struct page *page;
+ pgoff_t index, pidx;
int i;
index = in->f_pos >> PAGE_CACHE_SHIFT;
@@ -180,30 +181,48 @@ static int __generic_file_splice_read(st
i = find_get_pages(mapping, index, nr_pages, pages);
/*
- * If not all pages were in the page-cache, we'll
- * just assume that the rest haven't been read in,
- * so we'll get the rest locked and start IO on
- * them if we can..
+ * common case - we found all pages, kick it off
*/
- while (i < nr_pages) {
- struct page *page;
- int error;
-
- page = find_or_create_page(mapping, index + i, GFP_USER);
- if (!page)
- break;
+ if (i == nr_pages)
+ goto splice_them;
- if (PageUptodate(page))
- unlock_page(page);
- else {
- error = mapping->a_ops->readpage(in, page);
- if (unlikely(error)) {
- page_cache_release(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, GFP_HIGHUSER);
+ 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;
}
-
- pages[i++] = page;
}
if (!i)
@@ -212,6 +231,7 @@ static int __generic_file_splice_read(st
/*
* Now we splice them into the pipe..
*/
+splice_them:
return move_to_pipe(pipe, pages, i, offset, len);
}
--
Jens Axboe
next prev parent reply other threads:[~2006-03-30 9:15 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-29 12:28 [PATCH][RFC] splice support Jens Axboe
2006-03-29 12:30 ` Jens Axboe
2006-03-29 13:15 ` Jeff Garzik
2006-03-29 13:27 ` Jens Axboe
2006-03-29 21:49 ` Nathan Scott
2006-03-29 20:06 ` Linus Torvalds
2006-03-29 20:42 ` Jens Axboe
2006-03-29 20:43 ` Jens Axboe
2006-03-29 21:14 ` Linus Torvalds
2006-03-30 6:17 ` Jens Axboe
2006-03-29 22:37 ` Andrew Morton
2006-03-30 0:50 ` Linus Torvalds
2006-03-30 1:04 ` Jeff Garzik
2006-03-30 1:20 ` Andrew Morton
2006-03-30 6:18 ` Jens Axboe
2006-03-30 2:08 ` Andrew Morton
2006-03-30 3:44 ` Nick Piggin
2006-03-30 7:21 ` Jens Axboe
2006-03-30 7:30 ` Andrew Morton
2006-03-30 7:33 ` Jens Axboe
2006-03-30 8:02 ` Jan Engelhardt
2006-03-30 3:10 ` Nick Piggin
2006-03-30 7:16 ` Jens Axboe
2006-03-30 8:09 ` Jan Engelhardt
2006-03-30 7:45 ` Jens Axboe
2006-03-30 8:02 ` Andrew Morton
2006-03-30 8:10 ` Jens Axboe
2006-03-30 8:25 ` Nick Piggin
2006-03-30 8:27 ` Andrew Morton
2006-03-30 8:50 ` Nick Piggin
2006-03-30 8:51 ` Jens Axboe
2006-03-30 9:15 ` Jens Axboe [this message]
2006-03-30 9:40 ` Andrew Morton
2006-03-30 9:45 ` Jens Axboe
2006-03-30 9:56 ` Andrew Morton
2006-03-30 10:01 ` Jens Axboe
2006-03-30 2:36 ` Nick Piggin
2006-03-30 7:00 ` Jens Axboe
2006-03-30 7:33 ` Nick Piggin
2006-03-30 8:54 ` KAMEZAWA Hiroyuki
2006-03-30 13:53 ` Jens Axboe
2006-03-30 14:05 ` KAMEZAWA Hiroyuki
2006-03-30 14:38 ` Jens Axboe
2006-03-30 14:55 ` KAMEZAWA Hiroyuki
-- strict thread matches above, loose matches on Subject: below --
2005-12-19 9:16 Jens Axboe
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=20060330091523.GQ13476@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.