From: Andrew Morton <akpm@osdl.org>
To: alexeyk@mysql.com, linuxram@us.ibm.com, nickpiggin@yahoo.com.au,
peter@mysql.com, linux-kernel@vger.kernel.org, axboe@suse.de
Subject: Re: Random file I/O regressions in 2.6 [patch+results]
Date: Thu, 20 May 2004 15:23:05 -0700 [thread overview]
Message-ID: <20040520152305.3dbfa00b.akpm@osdl.org> (raw)
In-Reply-To: <20040520145902.27647dee.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> There's still something wrong here. 2.6.6-bk+deadline is pretty equivalent
> to 2.4 from an IO scheduler point of view in this test. Yet it's a couple
> of percent slower.
>
> I don't know why you're still seeing significant discrepancies.
>
> What sort of disk+controller system are you using? If scsi, what is the
> tag queue depth set to? Is writeback caching enabled on the disk?
If the 2.4 and 2.6 disk accounting statitics are to be believed, they show
something interesting.
Workload is one run of
sysbench --num-threads=16 --test=fileio --file-total-size=2G --file-test-mode=rndrw run
on ext2.
2.4.27-pre2:
rio: 5549 (Read requests issued)
rblk: 259680 (Total sectors read)
wio: 42398 (Write requests issued)
wblk: 4368056 (Total sectors written)
2.6.6-bk, as:
reads: 5983
readsectors: 201192
writes: 22548
writesectors: 4343184
- Note that 2.6 read 20% less data from the disk. We observed this
before. It appears that 2.6 page replacements decisions are working
better for this workload.
- Despite that, 2.6 issued *more* read requests. So it is submitting
more, and smaller I/O's
- Both kernels wrote basically the same amount of data. 2.6 a little
less, perhaps because of fsync() optimisations.
- But 2.6 issued far fewer write requests. Half as many as 2.4 - a huge
difference. There are a number of reasons why this could happen but
frankly, I don't have a clue what's going on in there.
Given that 2.6 is issuing less IO requests it should be performing faster
than 2.4. The reason that the two kernels are achieving about the same
throughput despite this is that the disk is performing writeback caching
and is absorbing 2.4's smaller write requests.
I set the IDE disk to do writethrough (hdparm -W0):
2.6.6-bk, as:
Time spent for test: 89.9427s
0.04s user 5.24s system 1% cpu 4:51.62 total
2.4.27-pre2:
Time spent for test: 107.8293s
0.04s user 6.00s system 1% cpu 7:26.47 total
as expected.
Open questions are:
a) Why is 2.6 write coalescing so superior to 2.4?
b) Why is 2.6 issuing more read requests, for less data?
c) Why is Alexey seeing dissimilar results?
next prev parent reply other threads:[~2004-05-20 22:20 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-02 19:57 Random file I/O regressions in 2.6 Alexey Kopytov
2004-05-03 11:14 ` Nick Piggin
2004-05-03 18:08 ` Andrew Morton
2004-05-03 20:22 ` Ram Pai
2004-05-03 20:57 ` Andrew Morton
2004-05-03 21:37 ` Peter Zaitsev
2004-05-03 21:50 ` Ram Pai
2004-05-03 22:01 ` Peter Zaitsev
2004-05-03 21:59 ` Andrew Morton
2004-05-03 22:07 ` Ram Pai
2004-05-03 23:58 ` Nick Piggin
2004-05-04 0:10 ` Andrew Morton
2004-05-04 0:19 ` Nick Piggin
2004-05-04 0:50 ` Ram Pai
2004-05-04 6:29 ` Andrew Morton
2004-05-04 15:03 ` Ram Pai
2004-05-04 19:39 ` Ram Pai
2004-05-04 19:48 ` Andrew Morton
2004-05-04 19:58 ` Ram Pai
2004-05-04 21:51 ` Ram Pai
2004-05-04 22:29 ` Ram Pai
2004-05-04 23:01 ` Alexey Kopytov
2004-05-04 23:20 ` Andrew Morton
2004-05-05 22:04 ` Alexey Kopytov
2004-05-06 8:43 ` Andrew Morton
2004-05-06 18:13 ` Peter Zaitsev
2004-05-06 21:49 ` Andrew Morton
2004-05-06 23:49 ` Nick Piggin
2004-05-07 1:29 ` Peter Zaitsev
2004-05-10 19:50 ` Ram Pai
2004-05-10 20:21 ` Andrew Morton
2004-05-10 22:39 ` Ram Pai
2004-05-10 23:07 ` Andrew Morton
2004-05-11 20:51 ` Ram Pai
2004-05-11 21:17 ` Andrew Morton
2004-05-13 20:41 ` Ram Pai
2004-05-17 17:30 ` Random file I/O regressions in 2.6 [patch+results] Ram Pai
2004-05-20 1:06 ` Alexey Kopytov
2004-05-20 1:31 ` Ram Pai
2004-05-21 19:32 ` Alexey Kopytov
2004-05-20 5:49 ` Andrew Morton
2004-05-20 21:59 ` Andrew Morton
2004-05-20 22:23 ` Andrew Morton [this message]
2004-05-21 7:31 ` Nick Piggin
2004-05-21 7:50 ` Jens Axboe
2004-05-21 8:40 ` Nick Piggin
2004-05-21 8:56 ` Spam: " Andrew Morton
2004-05-21 22:24 ` Alexey Kopytov
2004-05-21 21:13 ` Alexey Kopytov
2004-05-26 4:43 ` Alexey Kopytov
2004-05-11 22:26 ` Random file I/O regressions in 2.6 Bill Davidsen
2004-05-04 1:15 ` Andrew Morton
2004-05-04 11:39 ` Nick Piggin
2004-05-04 8:27 ` Arjan van de Ven
2004-05-04 8:47 ` Andrew Morton
2004-05-04 8:50 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040520152305.3dbfa00b.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=alexeyk@mysql.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=nickpiggin@yahoo.com.au \
--cc=peter@mysql.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox