From: Andrew Morton <akpm@digeo.com>
To: linux-kernel@vger.kernel.org
Subject: IO scheduler benchmarking
Date: Thu, 20 Feb 2003 21:23:04 -0800 [thread overview]
Message-ID: <20030220212304.4712fee9.akpm@digeo.com> (raw)
Following this email are the results of a number of tests of various I/O
schedulers:
- Anticipatory Scheduler (AS) (from 2.5.61-mm1 approx)
- CFQ (as in 2.5.61-mm1)
- 2.5.61+hacks (Basically 2.5.61 plus everything before the anticipatory
scheduler - tweaks which fix the writes-starve-reads problem via a
scheduling storm)
- 2.4.21-pre4
All these tests are simple things from the command line.
I stayed away from the standard benchmarks because they do not really touch
on areas where the Linux I/O scheduler has traditionally been bad. (If they
did, perhaps it wouldn't have been so bad..)
Plus all the I/O schedulers perform similarly with the usual benchmarks.
With the exception of some tiobench phases, where AS does very well.
Executive summary: the anticipatory scheduler is wiping the others off the
map, and 2.4 is a disaster.
I really have not sought to make the AS look good - I mainly concentrated on
things which we have traditonally been bad at. If anyone wants to suggest
other tests, please let me know.
The known regressions from the anticipatory scheduler are:
1) 15% (ish) slowdown in David Mansfield's database run. This appeared to
go away in later versions of the scheduler.
2) 5% dropoff in single-threaded qsbench swapstorms
3) 30% dropoff in write bandwidth when there is a streaming read (this is
actually good).
The test machine is a fast P4-HT with 256MB of memory. Testing was against a
single fast IDE disk, using ext2.
next reply other threads:[~2003-02-21 5:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-21 5:23 Andrew Morton [this message]
2003-02-21 5:23 ` iosched: parallel streaming reads Andrew Morton
2003-02-21 5:24 ` iosched: effect of streaming write on interactivity Andrew Morton
2003-02-21 5:25 ` iosched: effect of streaming read " Andrew Morton
2003-02-21 5:25 ` iosched: time to copy many small files Andrew Morton
2003-02-21 5:26 ` iosched: concurrent reads of " Andrew Morton
2003-02-21 5:27 ` iosched: impact of streaming write on streaming read Andrew Morton
2003-02-21 5:27 ` iosched: impact of streaming write on read-many-files Andrew Morton
2003-02-21 5:27 ` iosched: impact of streaming read " Andrew Morton
2003-02-21 10:40 ` Andrea Arcangeli
2003-02-21 10:55 ` Nick Piggin
2003-02-21 11:23 ` Andrea Arcangeli
2003-02-21 21:11 ` Andrew Morton
2003-02-23 15:16 ` Andrea Arcangeli
2003-02-25 12:02 ` Pavel Machek
2003-02-21 5:28 ` iosched: effect of streaming read on streaming write Andrew Morton
2003-02-21 6:51 ` IO scheduler benchmarking David Lang
2003-02-21 8:16 ` Andrew Morton
2003-02-21 10:31 ` Andrea Arcangeli
2003-02-21 10:51 ` William Lee Irwin III
2003-02-21 11:08 ` Andrea Arcangeli
2003-02-21 11:17 ` Nick Piggin
2003-02-21 11:41 ` Andrea Arcangeli
2003-02-21 21:25 ` Andrew Morton
2003-02-23 15:09 ` Andrea Arcangeli
2003-02-21 11:34 ` William Lee Irwin III
2003-02-21 12:38 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2003-02-25 5:35 rwhron
2003-02-25 6:38 ` Andrew Morton
2003-02-25 12:59 rwhron
2003-02-25 22:09 ` Andrew Morton
2003-02-25 21:57 rwhron
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=20030220212304.4712fee9.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
/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