Messages in this thread | | | Date | Sun, 18 Jul 1999 21:07:12 +0200 | From | Jamie Lokier <> | Subject | Re: [RFC] - Some notions that I would like comments on |
| |
Chuck Lever wrote: > 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. > > 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. > > however, if the cluster size is 128k, and the requested page is in the > second half of the cluster, then you've "read behind." on the other hand > by triggering the next cluster, you have 128k of potentially more > interesting data, since more fresh data is likely to be ahead of the > current page request. > > i may have missed your point, though.
From this & your next message I think you have :)
It's not about the size of clusters or having potentially more data in cache already. It's about having _all_ the data in cache before it's needed no matter how large the file.
This is done by tracking soft page faults -- when a page that is _already_ in cache is mapped into the process on a fault. In other words, the found_page case is the interesting one here. no_cached_page is also interesting but is never reached once sequential readahead reaches a steady state!
The net result is once the readahead window opens up enough, filemap_nopage never waits on I/O, not even once per cluster. With the code in place it might even be worth using readahead that's smaller than the random access readaround cluster size. More I/Os, less memory used.
-- 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/
| |