Re: [PATCH/RFC] Simplified Readahead

From: Steven Pratt
Date: Mon Sep 27 2004 - 10:42:31 EST


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/