>His torvaldsness rejected a patch that made mlock callable from inside
drivers
>to do this sort of stuff. So thats not a possibility.
I'm working on high-end digital video solutions (mainly MacOS drivers and
software), and the company I'm working for is considering using Linux for
some new applications and embedded video systems.
However, we need direct i/o. It's just not possible to do things with
such a throughtput as required by uncompressed digital video without
direct DMA from/to user buffers. The driver must be able to lock user
buffers for the duration of the i/o, gather a table of physical locations
and send it to the HW scatter/gather DMA controller.
This must be done when reading/writing data to/from disk (note that in
this case, we more often have to DMA directly to the framebuffer, which
is a different story, but we need, sometimes, to DMA to/from user
memory). This must also be done when driving a DMA capable frame capture
device, and copying the datas just makes things unuseable.
I think there are others cases where this should be interesting, like for
example when copying large files since in this case, caching is just a
waste of cache space, especially with very large/very fast disk
controllers (typically used in video solutions).
I don't say that we must promote direct I/O all the time, but there are
cases where accessing user pages from the HW is a real _big_ benefit or
is even necessary to keep up with throughput. All OSes I know about are
able to do that (NT can, but it's a little bit tricky, even MacOS, which
is not really an OS can do it: it has an esoteric call named
PrepareMemoryForIO that handles locking and cache coherency, returns you
the list of pages with physical addresses, and supports partial
preparation in case not enough physical memory is available).
I think what Linux needs is something similar so that it's not too much
platform dependant: A call that handle preparing of a user buffer and
that returns a list of pages bus addresses. A balancing call is needed to
release them. Preparation can fail completely or partialy (it may be able
to prepare only a portion of the buffer).
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/