Messages in this thread |  | | | From | Daniel Phillips <> | | Subject | Re: [resent PATCH] Re: very slow parallel read performance | | Date | Tue, 28 Aug 2001 03:54:37 +0200 |
| |
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/
|  |