Re: [PATCH/RFC] Simplified Readahead

[Steven Pratt]

Andrew Morton wrote:

> Steven Pratt <slpratt@xxxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/