On Fri, 16 Jul 1999 11:30:22 -0400 (EDT), Chuck Lever <cel@monkey.org> said:
> On Fri, 16 Jul 1999, Jamie Lokier wrote:
>> I don't see how it will. Doubling the cluster size just halves the
>> number of times when we get the latency hit of a synchronous read of the
>> first page in a cluster.
> as i understand it, when a page fault occurs and the requested page isn't
> already in the page cache, the whole cluster is read in. however, the
> read operations are non-blocking -- after all the reads are scheduled,
> filemap_nopage waits for the specific requested page.
Correct.
> so, if you want a page fault to trigger the next cluster too, a way of
> doing that easily with the current code base is to schedule all the reads
> for the current cluster, then schedule all the reads for the next cluster,
> then wait for the requested page. that's almost identical to doubling the
> cluster size.
Yes. This is exactly what you'd want to optimise MAP_SEQUENTIAL maps.
> however, if the cluster size is 128k, and the requested page is in the
> second half of the cluster, then you've "read behind."
Not quite. We don't trigger the cluster readaround unless the page is
missing from the cache altogether. For sequential accesses, we
basically guarantee that all accesses to the rest of the cluster are in
cache once the first page fault in the cluster has been taken. The IO
may not be complete yet, but the cache data structures will be in place.
In other words, the clustering readaround will trigger a readbehind for
sequential accesses.
--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/