Re: [resent PATCH] Re: very slow parallel read performance

[Daniel Phillips <phillips@bonn-fries.net>]

On August 25, 2001 10:52 pm, Rik van Riel wrote:
> On Sat, 25 Aug 2001, Marc A. Lehmann wrote:
> > On Sat, Aug 25, 2001 at 08:15:44PM +0100, Alan Cox 
<alan@lxorguk.ukuu.org.uk> wrote:
> > > How much disk and bandwidth can you afford. With vsftpd its certainly 
over
> > > 1000 parallal downloads on a decent PII box
> >
> > exactly this is a point: my disk can do 5mb/s with almost random
> > seeks, and linux indeed reads 5mb/s from it. but the userpsace process
> > doing read() only ever sees 2mb/s because the kernel throes away all
> > the nice pages.
> 
> The trick here is for the kernel to throw away the pages
> the processes have already used and keep in memory the
> data we have not yet used.

Reality check time.  Quoting Marc from the beginning of the thread:

> I tested the following under linux-2.4.8-ac8, linux-2.4.8pre4 and
> 2.4.5pre4, all had similar behaviour.

2.4.5pre4 has drop-behind and so does -ac8.  Still, if the readahead window 
is too large then drop-behind isn't going to help a lot.

Let's test the idea that readahead is the problem.  If it is, then disabling 
readahead should make the lowlevel disk throughput match the highlevel 
throughput.  Marc, could you please try it with this patch:

--- ../2.4.9.clean/mm/filemap.c	Thu Aug 16 14:12:07 2001
+++ ./mm/filemap.c	Sun Aug 26 02:24:50 2001
@@ -886,6 +886,7 @@
 
 	raend = filp->f_raend;
 	max_ahead = 0;
+return;
 
 /*
  * The current page is locked.