[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.040 / U:1.976 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site