lkml.org 
[lkml]   [2001]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: [resent PATCH] Re: very slow parallel read performance
Date
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.
-
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/
\
 
 \ /
  Last update: 2005-03-22 12:58    [W:0.244 / U:0.024 seconds]
©2003-2011 Jasper Spaans. Advertise on this site