Re: [patch 6/12] hold atomic kmaps across generic_file_read

Jeff Garzik
2002-08-10T18:49:06Z

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