From: Michal Ostrowski <mostrows@styx.uwaterloo.ca>
To: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: Poor I/O Performance (10x slower than 2.2)
Date: Wed, 31 May 2000 23:29:10 -0400 (EDT) [thread overview]
Message-ID: <14645.55430.196015.898700@styx.uwaterloo.ca> (raw)
I've noticed some horrible I/O performance in recent 2.3 kernels. My
first guess was that this was related to the various VM problems that
have been running rampant recently, but now I'm not so sure. Even
though I've been reading reports that VM performance has been
improving, I've seen no noticeable impact on my test results.
My test program performs a series of reads at random offests into a 1
GB sized file (on an ext2 fs). There are 1000 reads in total, and
each read operations reads some pre-determined number of blocks. The
application uses 1,4 or 10 kernel threads to perform this task. The
threads all quit once the total number of reads between all of them
reaches 1000 and the time to run the application is reported.
I've run this application on several combinations of kernels and
hardware. The hardware was a Celeron 500 or Dual PIII 550's with
7200RPM U2W SCSI drives (aic7880/aic7890 controllers) and 256 MB RAM.
The kernels I've used have varied from 2.3.99-pre1 to 2.4.0-test1-ac7,
however the kernel version used seems to have little impact on the
overall results.
The numbers I find really troublesome are the ones where I've got 10
threads and 32 blocks per read. What makes this case troublesome is
that I've seen a 2.2.14 kernel (on the dual processor box) run the
test with the same parameters in 34 seconds (as opposed to 340).
Regardless of how unrealistic my test application is, I don't think
that such a change in running time between 2.2.14 and 2.3.99-pre9 is
intentional.
My concern is that the running times increase so dramatically as the
number of blocks read per read operations increases, and that
increasing the number of threads has such a dramatically negative
impact.
Celeron 500 Dual PIII 550
test1-ac7 2.3.99-pre9
Threads Blocks Time To Complete 1000 Reads (seconds)
per
Read
1 4 7.6 18.2
1 8 9.9 21.6
1 16 21.0 28.5
1 32 22.0 32.3
4 4 8.2 17.3
4 8 9.1 19.7
4 16 15.2 21.1
4 32 20.2 28.5
10 4 6.4 7.6
10 8 6.9 9.4
10 12 9.0
10 13 96.9
10 16 114 223
10 32 290 345 *
* 2.2.14 runs this test in 34 seconds.
Michal Ostrowski
mostrows@styx.uwaterloo.ca
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next reply other threads:[~2000-06-01 3:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-01 3:29 Michal Ostrowski [this message]
2000-06-01 11:26 ` Rik van Riel
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=14645.55430.196015.898700@styx.uwaterloo.ca \
--to=mostrows@styx.uwaterloo.ca \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.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