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    [W:0.049 / U:91.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site