Messages in this thread | | | Date | Thu, 25 Jun 1998 23:16:38 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Thread implementations... |
| |
On Fri, 26 Jun 1998, MOLNAR Ingo wrote: > > no there is a much more important difference in favor of sendfile(), it's > the number of 'cursors' active within the system, and the timing of the > movement of these cursors and the coupling between them.
Note that the final word is "simplicity".
I looked into this today, and I can make a "sendfile()" in not much more than fifty lines of new code and some clever re-organization of the "generic_file_read()" function - so that file reading and sendfile() would use the same basic engine (which means that sendfile() would automatically get the proper read-ahead logic etc - something I definitely don't want to duplicate).
The approach I was thinking about was essentially the same one I did for "readdir()" when the same problem happened - we needed to get the same data into multiple output formats. Readdir() has an "actor" function that determines exactly how the dirent looks and where it goes in user space.
Sendfile() would do the same for file reading, and would allow you to have different "actor" functions where one would be a straight copy to user space (ie the read() functionality we have now), and one would instead do a "write()" to whatever other file descriptor you'd have available.
The only problem is that the added re-organization is nontrivial, and it needs some thinking about the best interface internally.
People who like mmap() just don't realize how expensive it is. Shuffing a page around in virtual memory is not all that much less expensive than copying it in the first place, and is a lot more complex conceptually with all the rules about copy-on-write and shared memory etc. You can easily blow the cache advantage you get on using up your icache instead.
mmap() tends to make the most sense only for fairly "static" use. Loading a binary is a perfect use for mmap(). There are others. But thinking that mmap() is the solution for zero-copy is very shortsighted. Yes, memory bandwidth is scarce, but mmap() has problems.
A lot of systems are actually more constrained by icache than by dcache behaviour. Think about that too, when you think zero-copy. Don't get fooled into thinking that "CPU cycles are cheap".
Also note that there are still various broken systems with virtual caches etc crap. Suddenly mmap() can become a major loss performance-wise.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |