On Wed, 2006-01-11 at 11:43 -0800, Andrew Morton wrote:
> Mingming Cao <[email protected]> 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) ...
Thanks,
Mingming
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]