From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Gerd Knorr <kraxel@bytesex.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: changes to kiobuf support in 2.4.(?)4
Date: Fri, 3 Aug 2001 13:32:28 +0200 [thread overview]
Message-ID: <20010803133228.P750@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <10108012254.ZM192062@classic.engr.sgi.com> <20010802084259.H29065@athlon.random> <slrn9mi3g9.36p.kraxel@bytesex.org>
In-Reply-To: <slrn9mi3g9.36p.kraxel@bytesex.org>; from kraxel@bytesex.org on Thu, Aug 02, 2001 at 08:23:37AM +0000
On Thu, Aug 02, 2001 at 08:23:37AM +0000, Gerd Knorr wrote:
> > The reason of the large allocation and to put the bh inside the kiobuf
> > is that if we do a small allocation then we end with a zillion of
> > allocations of the bh and freeing of the bh at every I/O!! (not even at
> > every read/write syscall, much more frequently)
>
> That is true for block device I/O only. Current bttv versions are using
> kiobufs to lock down user pages for DMA. But I don't need the bh's to
> transfer the video frames ...
This is another problem. We miss a whole layer of fast streaming
and chunking IO, which is not meant for block devices.
The most practical example would be the sg-driver, but there are
other things which require this kind of semantic:
Transmit Buffer via DMA to device (and programming it for
operations on that buffer) and possible receiving sth. back.
We need no reordering here, but would like to do the DMA directly
from user space buffers.
Examples:
- GiMP plugin, which renders some complex algorithm on a DSP.
- Crypto (Co-)processors, which encrypt data streams
- Screengrabbers, which can grab a specific area.
- (intelligent, multi) data aquisistion devices (large sensor
arrays)
...
I would like to have a thing like the zero copy IO in the network
layer, but not done with NICs only, but with ANY device.
For the DSP case (which might be the most complex one) I did some
research already, but I don't like to see this work duplicated
over and over again.
I built transfer structs similar to BHs but more simply and have
a queue of that per device and allocate transfers from a slab.
The blocking and unblocking is done in the driver anyway. I only
try to do zero copy IO, if I have complete pages, which
simplifies it a "little" ;-)
Without the coalescing and reordering it's pretty simple.
What do the gurus think here?
Regards
Ingo Oeser
--
You mean a kill file only kills email!!!! DAMN!!!! All these years
I thought I was doing the gene pool some good...
--- "Clint Wolff" <vaxman@qwest.net>
next prev parent reply other threads:[~2001-08-03 11:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-02 5:55 Jeremy Higdon
2001-08-02 6:43 ` Andrea Arcangeli
2001-08-02 7:31 ` Jeremy Higdon
2001-08-02 7:45 ` Andrea Arcangeli
2001-08-02 8:10 ` Jeremy Higdon
2001-08-02 8:24 ` Andrea Arcangeli
2001-08-02 8:42 ` Jeremy Higdon
2001-08-02 9:11 ` Andrea Arcangeli
2001-08-02 9:25 ` Jeremy Higdon
2001-08-02 10:00 ` Andrea Arcangeli
2001-08-02 8:23 ` Gerd Knorr
2001-08-03 11:32 ` Ingo Oeser [this message]
2001-08-03 12:45 ` Andrea Arcangeli
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=20010803133228.P750@nightmaster.csn.tu-chemnitz.de \
--to=ingo.oeser@informatik.tu-chemnitz.de \
--cc=kraxel@bytesex.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®