From: Andrew Morton <akpm@osdl.org>
To: Alexey Kopytov <alexeyk@mysql.com>
Cc: 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: Wed, 19 May 2004 22:49:57 -0700 [thread overview]
Message-ID: <20040519224957.202dd89c.akpm@osdl.org> (raw)
In-Reply-To: <200405200506.03006.alexeyk@mysql.com>
Alexey Kopytov <alexeyk@mysql.com> wrote:
>
> Ram Pai wrote:
>
> >Attached the cleaned up patch and the performance results of the patch.
> >
> >Overall Observation:
> > 1.Small improvement with iozone with the patch, and overall
> > much better performance than 2.4
> > 2.Small/neglegible improvement with DSS workload.
> > 3.Negligible impact with sysbench, but results worser than
> > 2.4 kernels
>
> Ram, can you clarify the status of this patch please?
Everything we have is now in Linus's tree. And in 2.6.6-mm4.
> I ran the same sysbench test on my hardware with patched 2.6.6 and got
> 122.2348s execution time, i.e. almost the same results as in the original
> tests. Is this patch an intermediate step to improve the sysbench workload on
> 2.6, or it just addresses another problem?
The patches in Linus's tree improve sysbench significantly here. It's a
256MB 2-way with IDE disks, writeback caching enabled:
sysbench --num-threads=16 --test=fileio --file-total-size=2G --file-test-mode=rndrw run
2.4.27-pre2, ext2:
Time spent for test: 61.0240s
0.06s user 6.03s system 4% cpu 2:05.95 total
Time spent for test: 60.8456s
0.11s user 5.49s system 4% cpu 2:04.94 total
2.6.6, CFQ, ext2:
Time spent for test: 85.6614s
0.05s user 5.66s system 3% cpu 2:26.75 total
Time spent for test: 85.2090s
0.06s user 5.32s system 3% cpu 2:24.75 total
2.6.6-bk, CFQ, ext2:
Time spent for test: 66.7717s
0.04s user 5.54s system 4% cpu 2:06.19 total
Time spent for test: 67.5666s
0.04s user 5.10s system 4% cpu 2:06.72 total
2.6.6, as, ext2:
Time spent for test: 83.8358s
0.07s user 5.89s system 4% cpu 2:22.92 total
Time spent for test: 83.8068s
0.06s user 5.34s system 3% cpu 2:21.33 total
2.6.6-bk, AS, ext2:
Time spent for test: 62.5316s
0.05s user 5.27s system 4% cpu 2:01.28 total
Time spent for test: 62.7401s
0.04s user 5.17s system 4% cpu 2:00.50 total
2.6.6, deadline, ext2:
Time spent for test: 103.0084s
0.06s user 5.76s system 3% cpu 2:40.74 total
Time spent for test: 101.9648s
0.07s user 5.35s system 3% cpu 2:38.83 total
2.6.6-bk, deadline, ext2:
Time spent for test: 63.3405s
0.03s user 5.49s system 4% cpu 2:01.05 total
Time spent for test: 63.5288s
0.03s user 5.05s system 4% cpu 2:00.78 total
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?
next prev parent reply other threads:[~2004-05-21 23:58 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 [this message]
2004-05-20 21:59 ` Andrew Morton
2004-05-20 22:23 ` Andrew Morton
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=20040519224957.202dd89c.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.