Messages in this thread | | | Date | Thu, 25 Jun 1998 18:25:14 +0200 | From | Erik Corry <> | Subject | Re: Thread implementations... |
| |
On Thu, Jun 25, 1998 at 11:56:56AM -0400, Amsden, Zachary wrote: > I assume you are talking about something like: > > caddr_t buf = mmap(0, len, PROT_READ | PROT_WRITE, > MAP_FILE | MAP_SHARED, ofd, 0); > mmap(buf, len, PROT_READ, MAP_FIXED | MAP_FILE | > MAP_SHARED, ifd, 0); > > So the two mmap overlap and automatically copy > data.
No, I meant
caddr_t buf = mmap(0, len, PROT_READ, MAP_FILE | MAP_SHARED, ifd, 0); write(ofd, buf, len);
If we make the write work directly from user space (if we need to lock down the memory for DMA, we can put any process/thread that tries to unmap it to sleep) and get rid of copying for mmap, then we are down to the minimum number of copies.
This seems like a good idea quite apart from this little trick. Unification of page and buffer cache is planned anyway according to http://www.caip.rutgers.edu/~davem/vfsmm.html which removes the copying stage from mmapped files if I understand it rightly.
> 1) It requires us to specify the number of bytes > to be written and map this into our address > space (mapping could be a big problem with > large >1gb files).
If they are that big, you can map them 100MB at a time.
> mmap() does have significant overhead
CPU overhead. The question is whether that is the bottleneck. In the post you replied to, I was addressing the question of whether sendfile saves us memory.
I'm not quite sure why mmap is so expensive, and whether we can recognise and special-case the idiom above (where the mapped memory is only accessed from within the write routine(s) of the kernel.)
-- Erik Corry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |