From: Jens Axboe <jens.axboe@oracle.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: marty <martyleisner@yahoo.com>,
linux-kernel@vger.kernel.org, martin.leisner@xerox.com
Subject: Re: disk IO directly from PCI memory to block device sectors
Date: Fri, 26 Sep 2008 12:19:56 +0200 [thread overview]
Message-ID: <20080926101954.GW2677@kernel.dk> (raw)
In-Reply-To: <20080926110610.17603d30@lxorguk.ukuu.org.uk>
On Fri, Sep 26 2008, Alan Cox wrote:
> On Fri, 26 Sep 2008 11:11:35 +0200
> Jens Axboe <jens.axboe@oracle.com> wrote:
>
> > On Fri, Sep 26 2008, Alan Cox wrote:
> > > > What I'm looking is for a more generic/driver independent way of sticking
> > > > contents of PCI ram onto a disk.
> > >
> > > Ermm seriously why not have a userspace task with the PCI RAM mmapped
> > > and just use write() like normal sane people do ?
> >
> > To avoid the fault and copy, I would assume.
>
> It's a write to a raw partition so with O_DIRECT you won't have to copy
> and MAP_POPULATE will premap the object if even the first write wants to
> occur without faulting overhead.
You are still going through get_user_pages() for each write. As I would
imagine the writes would generally be large, the hit would not be too
bad (but it's still there).
Depending on the hardware, it may or may not be a big deal. But the path
from device to disk is definitely a lot bigger and more complex with the
mmap/write approach.
Another alternative would be using splice - if the pci device exposed a
char device node, you could support ->splice_read() there which would
just fill the pages into the pipe buffer. Then change the block device
fops ->splice_write() to go direct to the block device through a bio
instead of using the page cache based generic_file_splice_write(). Such
a change would actually make sense to do, if the block device has been
opened with O_DIRECT. And it would get you about the same performance as
doing it in-kernel, the only extra overhead would be two syscalls per
64k (well probably only one extra syscall, since you probably need an
ioctl/syscall to initiate the in-kernel activity as well). So just about
as free as you could get.
--
Jens Axboe
next prev parent reply other threads:[~2008-09-26 10:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-26 7:29 disk IO directly from PCI memory to block device sectors marty
2008-09-26 8:03 ` Jens Axboe
2008-09-26 8:46 ` Alan Cox
2008-09-26 9:11 ` Jens Axboe
2008-09-26 10:06 ` Alan Cox
2008-09-26 10:19 ` Jens Axboe [this message]
2008-09-26 11:34 ` Jens Axboe
2008-09-26 15:51 ` Leisner, Martin
2008-09-29 13:02 ` Jens Axboe
2008-10-01 19:05 ` Jens Axboe
2008-10-02 16:15 ` Leon Woestenberg
2008-10-02 16:32 ` 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=20080926101954.GW2677@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.leisner@xerox.com \
--cc=martyleisner@yahoo.com \
/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