Re: 2.6.4-mm1

Andrew Morton
2004-03-11T22:20:33Z

jlnance@unity.ncsu.edu wrote:
>
> On Wed, Mar 10, 2004 at 11:31:40PM -0800, Andrew Morton wrote:
> > This affects I/O scheduling potentially quite significantly. It is no
> > longer the case that the kernel will submit pages for I/O in the order in
> > which the application dirtied them. We instead submit them in file-offset
> > order all the time.
>
> Hi Andrew,
> I have a feeling this change might significantly improve the external
> sorting benchmark I emailed you ( http://lkml.org/lkml/2003/12/20/46 ).
> I will try running it when I get a chance and let you know.

That thing's still sitting in by Inbox awaiting attention :(

I just took a quick peek. The `testfile' file which it lays out is well
laid-out so yes, if you're seeking all over that file then 2.6.4-mm1 may
indeed help throughput.

But `tesfile.tmp' is not well laid-out. Looks like it was created seekily,
so its blocks are all jumbled up.

The code in 2.6.4-mm1 favours unjumbled-up files. The code in 2.4 and
2.6.4 favours jumbled-up files.

When kjournald performs writeback it favours jumbled-up files, even in
2.6.4-mm1.

So it's hard to say what will happen ;) I'll take a look later.

> It gives me a good excuse to get 2.6 kernels working on my systems :-)

Luddite.