Date: Fri, 24 Sep 2004 16:01:47 -0700
From: Andrew Morton <akpm@osdl.org>
To: Steven Pratt <slpratt@austin.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Simplified Readahead
Message-Id: <20040924160147.27dbc589.akpm@osdl.org>
In-Reply-To: <4154A2F7.1050909@austin.ibm.com>
References: <4152F46D.1060200@austin.ibm.com>
	<20040923194216.1f2b7b05.akpm@osdl.org>
	<41543FE2.5040807@austin.ibm.com>
	<20040924150523.4853465b.akpm@osdl.org>
	<4154A2F7.1050909@austin.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1464
Lines: 34

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.
> >  
> >
> Well if the app really does this asynchronously, does it matter that we 
> block?

??  Not sure what you mean.

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.

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