[lkml]   [2006]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectFall back io scheduler for 2.6.15?
On Wed, 2006-01-11 at 11:43 -0800, Andrew Morton wrote:
> Mingming Cao <> wrote:
> >
> > # time ./filetst -b 1048576 -w -f /mnt/a
> > 2.6.14 2.6.15
> > real 0m21.710s 0m25.773s
> > user 0m0.012s 0m0.004s
> > sys 0m14.569s 0m15.065s
> That's a big drop.
> Was it doing I/O, or was it all from pagecache?
> > I also found tiobench(sequential write test) and dbench has similar
> > regression between 2.6.14 and 2.6.15. Actually I found 2.6.15 rc2
> > already has the regression. Is this a known issue?
> No, it is not known.
> > Anyway I will continue looking at the issue...
> Thanks.
Hi, Andrew,

I did some trace, it turns out there isn't regression between 2.6.14 and
2.6.15, and there is no problem in ext3 filesystem. I am comparing
apple to orange: the tests were run on two different io schedulers. That
makes the bogus throughput difference that I reported to you earlier
this week.

I gave the same boot option "elevator=as" for both 2.6.14 and 2.6.15-rc2
(this has been working for me for a long time to get the anticipatory
scheduler on), but the results are, the io schedulers turned on on the
two kernels are different( see elevator_setup_default()). On 2.6.14, the
fall back io scheduler (if the chosen io scheduler is not found) is set
to the default io scheduler (anticipatory, in this case), but since
2.6.15-rc1, this semanistic is changed to fall back to noop.

Is there any reason to fall back to noop instead of as? It seems
anticipatory is much better than noop for ext3 with large sequential
write tests (i.e, 1G dd test) ...



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-01-14 02:14    [W:0.129 / U:0.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site