Messages in this thread Patch in this message |  | | | From | Daniel Phillips <> | | Subject | Re: [resent PATCH] Re: very slow parallel read performance | | Date | Sun, 26 Aug 2001 03:38:34 +0200 |
| |
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/
|  |