From: Jens Axboe <axboe@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, nickpiggin@yahoo.com.au
Subject: Re: [PATCH] splice: add support for SPLICE_F_MOVE flag
Date: Fri, 31 Mar 2006 09:08:14 +0200 [thread overview]
Message-ID: <20060331070814.GR13476@suse.de> (raw)
In-Reply-To: <20060330185956.54961b7b.akpm@osdl.org>
On Thu, Mar 30 2006, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > static void page_cache_pipe_buf_unmap(struct pipe_inode_info *info,
> > > struct pipe_buffer *buf)
> > > {
> > > - unlock_page(buf->page);
> > > + if (!buf->stolen)
> > > + unlock_page(buf->page);
> > > kunmap(buf->page);
> > > }
> >
> > There go our chances of ever getting rid of kmap(). Is it not feasible to
> > use atomic kmaps throughout this code?
>
> What are the kmaps for, anyway? afaict they're doing the
> kmap-the-page-while-we-run-some-a_ops thing which ceased being a
> requirement 3-4 years ago.
Not quite so, it's because the ->map serve as both a pin and address map
helper. The splice stuff doesn't actually need the kmap(), only for the
case where we have to copy the page. And it would be just as easy to
map that ourselves in that case.
There's a comment about that in the splice file.
> The general approach we should take is that the code which actually
> modifies a page's contents is the code which is responsible for kmapping
> that page. Use an atomic kmap, memcpy-or-memset, atomic kunmap. Just four
> or five lines.
>
> If we can do that, pipe_buf_operations.map/unmap can be removed.
The page cache stuff still needs to sanity check the page, before
allowing the caller to map it, so it cannot go. But it can be optimized.
--
Jens Axboe
prev parent reply other threads:[~2006-03-31 7:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200603302109.k2UL9ET0012970@hera.kernel.org>
2006-03-31 0:35 ` [PATCH] splice: add support for SPLICE_F_MOVE flag Andrew Morton
2006-03-31 2:59 ` Andrew Morton
2006-03-31 7:08 ` Jens Axboe [this message]
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=20060331070814.GR13476@suse.de \
--to=axboe@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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