Linus Torvalds wrote:
> And read() is often the much nicer interface, simply because you don't
> need to worry about the size of the file up-front etc.
>
> Also, because of the delayed nature of mmap()/fault, it has some strange
> behaviour if somebody is editing your file in the middle of the compile -
> with read() you might get strange syntax errors if somebody changes the
> file half-way, but with mmap() your preprocessor may get a SIGSEGV in the
> middle just because the file was truncated..
>
> In general, I think read() tends to be the right (and simpler) interface
> to use if you don't explicitly want to take advantage of the things mmap
> offers (on-demand mappings, no-write-back pageouts, VM coherency etc).
While working on a race-free rewrite of cp/mv/rm (suggested by Al), I
did overall-time benchmarks on read+write versus sendfile/stat versus
mmap/stat, and found that pretty much the fastest way under Linux 2.2,
2.4, and solaris was read+write of PAGE_SIZE, or PAGE_SIZE*2 chunks.
[obviously, 2.2 and solaris didn't do sendfile test]
The overhead of the extra stat and mmap/munmap syscalls seemed to be the
thing that slowed things down. sendfile was pretty fast, but still an
extra syscall, with an annoyingly large error handling case [only
certain files can be sendfile'd]
I sure would like an O_STREAMING flag, though... let a user app hint to
the system that the pages it is reading or writing are perhaps less
likely to be reused, or access randomly.... A copy-file syscall would
be nice, too, but that's just laziness talking....
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:22 EST