> You cannot mmap a stream source only block objects. Also you are then forced
> to work in the block sizes of the device, which can be huge causing massive
> resource management problems. The actual data that is used for the zero
> copy needs to end up in a pageable resource and pinned only when needed.
> Thus if you map a 2Mb video capture image you want it to end up on the
> user side. You can then sendfile/write that to disk or a network
with the temporary file solution we already have all of this, dont we?
(Lets just forget anonymous user-memory for a moment, i'll explain the
anonymous user-memory case later on). If we mmap() a temporary file, we
already have it 'visible by user-space' (so some real work can be done on
the data), and we also have all the copyfd() and sendfile() features that
do zero-copy IO to the very same pages. So the 'video server' thing would
work the following way:
- we mmap() a 2MB 'smallfile' (say all zeroes initial state)
- we do a copyfd(smallfile,framebuffer), in which copyfd()
instructs the capture-buffer DMA being done to the page-cache.
(this happens inside the kernel, the driver doesnt even notice
much from this)
- we do a sendfile(networksocket,smallfile), in which sendfile()
sends the result out to the network.
- [repeat, the whole thing is possibly done on several 2MB
buffers, to allow overlap]
no data is copied at all. (but it's all visible to user-space, we could
theoretically ... eg filter it or display a small ad-banner in one corner
of the frame :)
note that the above mechanizm works cleanly out of the page-cache!
Now, anonymous user-pages could be handled the same way, basically anonym
pages can be considered as data pages attached to 'temporary, user-only
files'. So we can 'page-cache enable' anonymous pages too: introduce a
special inode, which has a bmap() that walks the page-table (or vmas) to
find apropriate pages. (note that here we again see the same mechanizm we
have seen in the raw-IO patch, in a cleaner and more generic way) [this is
just a quick idea, i'm not sure wether it's possible this way, but it
doesnt sound too difficult. anonymous pages are not all that different
from 'named' mappings]
we do not have copyfd() yet, (or sendfile() where the target is the
page-cache too), but this is only a current limitation. (i'm worried a bit
how to solve the page aliasing issue here)
> So I need the low level DMA to user space but I don't need raw disk. What
> happens then is
>
> lock 2Mb
> blast data (<2mS)
> unlock 2Mb
>
> sendfile it (undefined completion time)
> [possible swapping I/O etc occurs during this]
yes exactly this is possible too, but through the page-cache.
> SCSI generic is a similar example where we want to DMA into user pages or
> from user pages in large chunks (scanners like their I/O in megabyte
> sized chunks or bigger).
yes i agree, we want to have the _result_ of moving data to user-visible
pages. The difference is, that the preferred solution is to have the
mechanism should go through the page-cache. (we are talking about the same
end-result, but a different mechanism)
-- mingo
-
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/