public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: linux-kernel@vger.kernel.org
Subject: iosched: parallel streaming reads
Date: Thu, 20 Feb 2003 21:23:52 -0800	[thread overview]
Message-ID: <20030220212352.3cfefeab.akpm@digeo.com> (raw)
In-Reply-To: <20030220212304.4712fee9.akpm@digeo.com>


Here we see how well the scheduler can cope with multiple processes reading
multiple large files.  We read ten well laid out 100 megabyte files in
parallel (ten readers):

	for i in $(seq 0 9)
	do
		time cat 100-meg-file-$i > /dev/null &
	done

2.4.21-pre4:

	0.00s user 0.18s system 2% cpu 6.115 total
	0.02s user 0.22s system 1% cpu 14.312 total
	0.01s user 0.19s system 1% cpu 14.812 total
	0.00s user 0.14s system 0% cpu 20.462 total
	0.02s user 0.19s system 0% cpu 23.887 total
	0.06s user 0.14s system 0% cpu 27.085 total
	0.01s user 0.26s system 0% cpu 32.367 total
	0.00s user 0.22s system 0% cpu 34.844 total
	0.01s user 0.21s system 0% cpu 35.233 total
	0.01s user 0.16s system 0% cpu 37.007 total

2.5.61+hacks:

	0.01s user 0.16s system 0% cpu 2:12.00 total
	0.01s user 0.15s system 0% cpu 2:12.12 total
	0.00s user 0.14s system 0% cpu 2:12.34 total
	0.01s user 0.15s system 0% cpu 2:12.68 total
	0.00s user 0.15s system 0% cpu 2:12.93 total
	0.01s user 0.17s system 0% cpu 2:13.06 total
	0.01s user 0.14s system 0% cpu 2:13.18 total
	0.01s user 0.17s system 0% cpu 2:13.31 total
	0.01s user 0.16s system 0% cpu 2:13.49 total
	0.01s user 0.19s system 0% cpu 2:13.51 total

2.5.61+CFQ:

	0.01s user 0.16s system 0% cpu 50.778 total
	0.01s user 0.16s system 0% cpu 51.067 total
	0.01s user 0.16s system 0% cpu 52.854 total
	0.01s user 0.17s system 0% cpu 53.303 total
	0.01s user 0.17s system 0% cpu 54.565 total
	0.01s user 0.18s system 0% cpu 1:07.39 total
	0.01s user 0.17s system 0% cpu 1:19.96 total
	0.00s user 0.17s system 0% cpu 1:28.74 total
	0.01s user 0.18s system 0% cpu 1:31.28 total
	0.01s user 0.18s system 0% cpu 1:32.34 total

2.5.61+AS

	0.01s user 0.17s system 0% cpu 27.995 total
	0.01s user 0.18s system 0% cpu 30.550 total
	0.00s user 0.17s system 0% cpu 31.413 total
	0.00s user 0.18s system 0% cpu 32.381 total
	0.01s user 0.17s system 0% cpu 33.273 total
	0.01s user 0.18s system 0% cpu 33.389 total
	0.01s user 0.15s system 0% cpu 34.534 total
	0.01s user 0.17s system 0% cpu 34.481 total
	0.00s user 0.17s system 0% cpu 34.694 total
	0.01s user 0.16s system 0% cpu 34.832 total


AS and 2.4 almost achieved full disk bandwidth.  2.4 does quite well here,
although it was unfair.

As an aside, I reran this test with the VM readahead wound down from the
usual 128k to just 8k:

2.5.61+CFQ:

	0.01s user 0.25s system 0% cpu 7:48.39 total
	0.01s user 0.23s system 0% cpu 7:48.72 total
	0.02s user 0.26s system 0% cpu 7:48.93 total
	0.02s user 0.25s system 0% cpu 7:48.93 total
	0.01s user 0.26s system 0% cpu 7:49.08 total
	0.02s user 0.25s system 0% cpu 7:49.22 total
	0.02s user 0.26s system 0% cpu 7:49.25 total
	0.02s user 0.25s system 0% cpu 7:50.35 total
	0.02s user 0.26s system 0% cpu 8:19.82 total
	0.02s user 0.28s system 0% cpu 8:19.83 total

2.5.61 base:

	0.01s user 0.25s system 0% cpu 8:10.53 total
	0.01s user 0.27s system 0% cpu 8:11.96 total
	0.02s user 0.26s system 0% cpu 8:14.95 total
	0.02s user 0.26s system 0% cpu 8:17.33 total
	0.02s user 0.25s system 0% cpu 8:18.05 total
	0.01s user 0.24s system 0% cpu 8:19.03 total
	0.02s user 0.27s system 0% cpu 8:19.66 total
	0.02s user 0.25s system 0% cpu 8:20.00 total
	0.02s user 0.26s system 0% cpu 8:20.10 total
	0.02s user 0.25s system 0% cpu 8:20.11 total

2.5.61+AS

	0.02s user 0.23s system 0% cpu 28.640 total
	0.01s user 0.23s system 0% cpu 28.066 total
	0.02s user 0.23s system 0% cpu 28.525 total
	0.01s user 0.20s system 0% cpu 28.925 total
	0.01s user 0.22s system 0% cpu 28.835 total
	0.02s user 0.21s system 0% cpu 29.014 total
	0.02s user 0.23s system 0% cpu 29.093 total
	0.01s user 0.20s system 0% cpu 29.175 total
	0.01s user 0.23s system 0% cpu 29.233 total
	0.01s user 0.21s system 0% cpu 29.285 total

We see here that the anticipatory scheduler is not dependent upon large
readahead to get good performance.




  reply	other threads:[~2003-02-21  5:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-21  5:23 IO scheduler benchmarking Andrew Morton
2003-02-21  5:23 ` Andrew Morton [this message]
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

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=20030220212352.3cfefeab.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