Messages in this thread | | | Date | Sat, 10 Aug 2002 14:52:49 -0400 | From | Jeff Garzik <> | Subject | Re: [patch 6/12] hold atomic kmaps across generic_file_read |
| |
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/
| |