Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 19 Jul 1999 13:41:46 +0100 (BST) | Subject | Re: [RFC] - Some notions that I would like comments on |
| |
Hi,
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/
| |