lkml.org 
[lkml]   [2004]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Strange IDE performance change in 2.6.1-rc1 (again)
    From
    Date
    On Wed, 2004-01-07 at 06:59, Paolo Ornati wrote:
    > On Tuesday 06 January 2004 00:19, you wrote:
    > > Sorry I was on vacation and could not get back earlier.
    > >
    > > I do not exactly know the reason why sequential reads on blockdevices
    > > has regressed. One probable reason is that the same lazy-read
    > > optimization which helps large random reads is regressing the sequential
    > > read performance.
    > >
    > > Note: the patch, waits till the last page in the current window is being
    > > read, before triggering a new readahead. By the time the readahead
    > > request is satisfied, the next sequential read may already have been
    > > requested. Hence there is some loss of parallelism here. However given
    > > that largesize random reads is the most common case; this patch attacks
    > > that case.
    > >
    > > If you revert back just the lazy-read optimization, you might see no
    > > regression for sequential reads,
    >
    > I have tried to revert it out:
    >
    > --- mm/readahead.c.orig 2004-01-07 15:17:00.000000000 +0100
    > +++ mm/readahead.c.my 2004-01-07 15:33:13.000000000 +0100
    > @@ -480,7 +480,8 @@
    > * If we read in earlier we run the risk of wasting
    > * the ahead window.
    > */
    > - if (ra->ahead_start == 0 && offset == (ra->start + ra->size -1)) {
    > + if (ra->ahead_start == 0) {
    > ra->ahead_start = ra->start + ra->size;
    > ra->ahead_size = ra->next_size;
    >
    > but the sequential read performance is still the same !
    >
    > Reverting out the other part of the patch (that touches mm/filemap.c) the
    > sequential read performance comes back like in 2.6.0.

    I tried on my lab machine with scsi disks. (I dont have access currently
    to a spare machine with ide disks.)

    I find that reverting the changes in mm/filemap.c and then reverting the
    lazy-read optimization gives much better sequential read performance on
    blockdevices. Is this your observation on IDE disks too?


    >
    > I don't know why... but it does.

    Lets see. I think my theory is partly the reason. But the changes in
    filemap.c seems to be influencing more.


    >
    > >
    > > Let me see if I can verify this,
    > > Ram Pai
    > >
    >
    > Bye

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