readahead(2) - Linux

Julian Elischer julian at elischer.org
Tue Mar 4 21:20:46 UTC 2008


Robert Watson wrote:
> On Mon, 3 Mar 2008, Julian Elischer wrote:
> 
>> Ivan Voras wrote:

>>
>> the aim is to load it into system memory but not copy anything into 
>> user memory.
> 
> In an ideal world (tm), a prefetch system call doesn't actually force 
> the I/O to happen, it just hints that if it did happen, life would then 
> be better. Then, in said ideal world (tm), the VM system can juggle 
> investing pages in memory and I/O capacity in heuristic read-ahead, 
> prefetch hints from the application, anonymously process memory, and 
> buffer cache, based on what is most effective for particular 
> applications or workloads.  Last time I read up on I/O prefetching 
> literature, it was considered quite difficult to place prefetch calls in 
> applications in a useful way, and that normal heuristic read-ahead, 
> which we already support, actually caught a high percentage of real 
> application cases since applications do tend to order and store data 
> usefully in files.  For certain applications, though, that doesn't help 
> much, and there isn't a way to tune "up" read-ahead prefetching, so it 
> could be we're no longer doing as good a job.


The assumption is that the application has a clue as to what it
wil need in the near future and is explicitly hinting to the
kernel to queue it for reading.

The equivalent would be to do something like an madvise on a
mmapped version of the file assuming that madvise can ask
for a page to be faulted in without blocking for it..

The key is that the process must not block when issuing
the request, as it doesn't want to wait for the data.


More information about the freebsd-hackers mailing list