Re: [PATCH/RFC] Simplified Readahead

[Steven Pratt <slpratt@austin.ibm.com>]

Andrew Morton wrote:

>Steven Pratt <slpratt@austin.ibm.com> wrote:
>  
>
>>>It's an application-specified readahead hint.  It should ideally be
>>>asynchronous so the application can get some I/O underway while it's
>>>crunching on something else.  If the queue is contested then the
>>>application will accidentally block when launching the readahead, which
>>>kinda defeats the purpose.
>>> 
>>>
>>>
>>>posix_fadvise(POSIX_FADV_WILLNEED) is used by applications to tell the
>>>kernel that the application will need that part of the file in the future. 
>>>Presumably, the application has something else to be going on with
>>>meanwhile.  Hence the application doesn't want to block.
>>>      
>>>
Ok, got it.

>>>Yes, the application will block when it does the subsequent read() anyway,
>>>but applications expect to block in read().  Seems saner this way.
>>>
>>>      
>>>
>>Just to be sure I have this correct, the readahead code will be invoked 
>>once on the POSIX_FADV_WILLNEED request, but this looks mostly like a 
>>regular read, and then again for the same pages on a real read?
>>    
>>
>
>
>yup.  POSIX_FADV_WILLNEED should just populate pagecache and should launch
>asynchronous I/O.
>

Well then this could cause problems (other than congestion) on both the 
current and new code since both will effectivly see 2 reads, the second 
of which may appear to be a seek backwards thus confusing the code 
slightly.  Would it be best to just special case the POSIX_FADV_WILLNEED 
and issue the I/O required (via do_page_cache_readahead) without 
updating any of the window or current page offset  information ? Of 
course adding the neccesary check for queue congestion.

Steve