Note, Stephen Tweedie's latest "go faster VM stripes" do this, a bit.
I mean the aligned 64k clustering page-in.
> I don't really see the problem: some indecision on an arbitrary limit?
> This is the same thing as prefetching with read(), isn't it? You don't
> know how much to prefetch with read, do you? As a worst case, why not
> have the same semantics as read -- prefetch the next page if you have to
> sleep to read it -- not optimal, but at least will bring mmap() to the
> performance of read().
mmap() tends to be used more for random access, so you have to be a bit
more cautious with the heuristics. Ok, if you can spot when an mmap()
is being used in a regular way.
> I always thought that mmap() should be fast, especially when you use
> it for IPC.
It is fast, just not asynchronous. (Wild, hand-waving theorist
warning): You can get the full speed of readahead with the zero-copy of
mmap() by running several threads through the file at the same time,
each thread accessing different pages in some good order. Here's where
I wave my hands very hard...
-- Jamie
-
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/