lkml.org 
[lkml]   [2001]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [resent PATCH] Re: very slow parallel read performance
Date
On August 28, 2001 02:05 am, Marcelo Tosatti wrote:
> On Tue, 28 Aug 2001, Dieter Nützel wrote:
>
> > [-]
> > > In the real-world case we observed the readahead was actually being
> > > throttled by the ftp clients. IO request throttling on the file read
> > > side would not have prevented cache from overfilling. Once the cache
> > > filled up, readahead pages started being dropped and reread, cutting
> > > the server throughput by a factor of 2 or so. On the other hand,
> > > performance with no readahead was even worse.
> > [-]
> >
> > Are you like some numbers?
>
> Note that increasing readahead size on -ac and stock tree will affect the
> system in a different way since the VM has different logics on drop
> behind.
>
> Could you please try the same tests with the stock tree? (2.4.10-pre and
> 2.4.9)

He'll need the proc max-readahead patch posted by Craig I. Hagan on Sunday
under the subject "Re: [resent PATCH] Re: very slow parallel read
performance".

There are two other big variables here: Reiserfs and dbench. Personally, I
question the value of doing this testing on dbench, it's too erratic.

--
Daniel
-
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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site