Messages in this thread |  | | | Date | Sun, 13 Dec 1998 18:50:35 +0100 (CET) | | From | MOLNAR Ingo <> | | Subject | Re: PATCH: Raw device IO for 2.1.131 |
| |
On Sun, 13 Dec 1998, Alan Cox wrote:
> 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/
|  |