On Mon, Apr 03, 2000 at 01:54:12AM +0100, Alan Cox wrote:
> > Read-ahead (there is no write ahead) at mmap(2) is constrained
> > to ONE instance per entire process memory space.
> > That alone makes use of mmap(2) rather inefficient, doesn't it ?
>
> That seems odd. Quite a few programs open a file multiple times and mmap
> using different fd's to try and get multiple readaheads. I've never looked
> to see if that works on Linux too
Sure, read(2) does read-ahead on FD basis, but the entire
process memory context (when using mmap(2)/munmap(2) on FD)
has only one read-around, as Andrea said, and it isn't exactly
FD based, even though the mapped range is FD related.
One can mmap(2) something in, and close the FD on which the
mapped range is related, but the range remains in the memory.
Of course only after it is munmap()ed, and last reference count
goes away, the inode becomes discarded.
A triple buffering scheme per each fd is best approach I think.
(And using FD-based IO.)
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:09 EST