Re: mmap() is slower than read() on SCSI/IDE on 2.0 and 2.1

Stephen C. Tweedie (sct@redhat.com)
Wed, 16 Dec 1998 12:28:28 GMT


Hi,

On Tue, 15 Dec 1998 14:42:28 +1300, Chris Wedgwood <cw@ix.net.nz> said:

> On Mon, Dec 14, 1998 at 08:58:41PM +0000, Stephen C. Tweedie wrote:
>> It will be pretty simple to add a soft-page-fault fencepost to the
>> page cache to allow us to prime the next readahead chunk before we
>> have finished accessing the current one in the case of sequential
>> access, which will allow us to sustain even faster sequential IO
>> rates on fast disks.

> But doesn't this assume we'll sequentially access mmap regions?

No. Done correctly, it assumes that we _might_ access them
sequentially, and that the readahead only kicks in if we do so. The
heuristic I am currently coding is that if the entire previous VA
cluster is currently mapped in the page tables, then the processor is
accessing all of the referenced pages and readahead is enabled.

This algorithm has many good properties: in particular, it does not
assume that there is only one readahead stream per vma. In numerical
codes it is very common to have multiple large arrays in memory, and we
may well be accessing all of those arrays sequentially at the same time.
In that case we have multiple readahead "cursors" active in the VM at
once, so we can't just use heuristics based on the address of the last
fault to recognise sequential access.

> I really don't fully understand why madvise is a bad thing, I don't
> see how the OS can possibly know better than the application about
> future access patterns....

The point is that there are many very common access patterns which the
O/S can, and should, recognise and optimise without the user needing to
tell us.

--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/