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