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:1.987 / U:0.388 seconds]
©2003-2011 Jasper Spaans. Advertise on this site