Re: disk throughput down in 2.5.8

Andrew Morton (akpm@zip.com.au)
Thu, 18 Apr 2002 18:34:54 -0700


Mikael Pettersson wrote:
>
> Is it just me or is disk I/O throughput way down in 2.5.8?
>
> I was preparing to build 2.4.19-pre7 on a box running 2.5.8,
> when I noticed that 'tar zxvf' on the kernel tarball seemed
> slow and jerky. So I ran
>
> cd /tmp; time tar zxf /path/to/linux-2.5.8.tar.gz
>
> on several boxes(*), comparing 2.4.19-pre7 with 2.5.8.
>
> On the older boxes (2 PentiumIIs and one K6-III), 2.5.8 was slower
> by factors of 2.3-4.5. A P4 with an IBM 60GXP "only" suffered a
> 40% slowdown.
>

I can't say that it's happening here. The time to untar
and sync a kernel tarball from /dev/sdb6 to /dev/sdb5:

2.4.19-pre4:
~/doit 6.55s user 3.69s system 53% cpu 19.225 total
2.4.19-pre7
~/doit 6.82s user 3.29s system 53% cpu 18.811 total
2.5.8:
~/doit 6.32s user 3.52s system 56% cpu 17.401 total

So 2.5.8 is a little quicker. Note that this time includes
"sync". 2.4.19-recent has more intelligent write-behind
than other kernels, and if you don't include the /bin/sync
time, you actually miss out on timing a lot of the I/O.
Which is a good feature in 2.4, but it only goes so far.

dbench throughput is down the tubes in 2.5.8 - partly because
the kernel is starting too many pdflush threads, and partly
because I (had to) take out the bit of code where bdflush
waits on I/O completion before looking for another wakeup.
That would be a waste of pdflush resources. It needs to
be addressed by other means, but not with the buffer LRUs.

-
-
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/