From: Douglas Gilbert <dougg@torque.net>
To: linux-kernel@vger.kernel.org
Cc: Alex Q Chen <aqchen@us.ibm.com>, linux-scsi@vger.kernel.org
Subject: Re: Zero Copy IO
Date: Sun, 08 Apr 2001 20:54:39 -0400 [thread overview]
Message-ID: <3AD1084F.A916D361@torque.net> (raw)
"Alex Q Chen" <aqchen@us.ibm.com> wrote:
> I am trying to find a way to pin down user space
> memory from kernel, so that these user space buffer
> can be used for direct IO transfer or otherwise
> known as "zero copying IO". Searching through the
> Internet and reading comments on various news groups,
> it would appear that most developers including Linus
> himself doesn't believe in the benefit of "zero
> copying IO". Most of the discussion however was based
> on network card drivers. For certain other drivers
> such as SCSI Tape driver, which need to handle great
> deal of data transfer, it would seemed still be more
> advantageous to enable zero copy IO than copy_from_user()
> and copy_to_user() all the data. Other OS such as AIX
> and OS2 have kernel functions that can be used to
> accomplish such a task. Has any ground work been done
> in Linux 2.4 to enable "zero copying IO"?
Alex,
The kiobufs mechanism in the 2.4 series is the appropriate
tool for avoiding copy_from_user() and copy_to_user().
The definitive driver is in drivers/char/raw.c which
does synchronous IO to block devices such as disks
(but is probably not appropriate for tapes).
The SCSI generic (sg) driver supports direct IO. The driver
in lk 2.4.3 has the direct IO code commented out while
a version that I'm currently testing (sg 3.1.18 at
www.torque.net/sg) has its direct IO code activated. I have
a web page comparing throughput times and CPU utilizations
at http://www.torque.net/sg/rbuf_tbl.html . My testing
indicates that the kiobufs mechanism is now working
quite well. For various reasons I still think that it
is best to default to indirect IO and let speed hungry
users enable dio (which is done in sg via procfs). Even
when the user selects direct IO is should be possible to
fall back to indirect IO. [Sg does this when a SCSI
adapter can't support direct IO (e.g. an ISA adapter).]
Since the SCSI tape (st) driver is structurally similar
to sg, it should be possible to add direct IO support
to st.
One thing to note is that when you let the user provide
the buffer for direct IO (e.g. with malloc) then on
the i386 it won't be contiguous from a bus address POV.
This means large scatter gather lists (typically with
each element 4 KB on i386) which can be time consuming
to load on some SCSI adapters. One way around this would
be for a driver to provide "malloc/free" like ioctls.
Doug Gilbert
next reply other threads:[~2001-04-09 0:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-09 0:54 Douglas Gilbert [this message]
2001-04-09 1:53 ` [QUESTIONS] Transision from pcmcia-cs to 2.4 built-in PCMCIA Ryan Mack
2001-04-09 9:04 ` David Woodhouse
2001-04-09 12:25 ` Zero Copy IO Jeremy Jackson
-- strict thread matches above, loose matches on Subject: below --
2001-04-08 23:31 Alex Q Chen
2001-04-09 0:13 ` Andi Kleen
2001-04-09 19:23 ` Alan Cox
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=3AD1084F.A916D361@torque.net \
--to=dougg@torque.net \
--cc=aqchen@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.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