On Sun, 18 Jul 1999 14:37:35 -0400 (EDT), Chuck Lever <cel@monkey.org>
said:
> right - i should have specified that the "readbehind" has negative effects
> for random accesses, but are not much of an issue for sequential accesses
> of an mmap'd file.
No. "Readaround" works well for the random access patterns seen when
accessing executable code. When running a library function, you
often end up invoking a lot of related functions which are called by
that function, and those are as likely to be earlier in the library
image as later.
Doing the clustered readaround in this situation maximises the speed at
which we page in contiguous large chunks of the library. Because we are
hitting nearby functions backwards as well as forwards, the lack of
universal readahead in this case really doesn't hurt much.
> the change to make the kernel read the next cluster during a page fault is
> actually very very simple. in mm/filemap.c filemap_nopage() ::
> now, this doesn't do anything special for MAP_SEQUENTIAL mmaps, but it
> gives you enough to try testing. i've found that it helps performance
> somewhat on a 128M server with SCSI disks, but hinders performance
> significantly on a 64M laptop with an IDE disk (no cache).
Slow disks plus less memory will always increase the cost involved in
doing even more speculative IO, yes.
> there are several other more significant optimizations that can be made
> here. i can post a patch against late 2.3 if anyone's interested.
A decent performance study of the effects of these changes would be far
more interesting than a simple list of the possible code variations!
I'd like to see the results you've just alluded to if you still have
them.
--Stephen
-
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/