public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: iosched: impact of streaming read on read-many-files
Date: Fri, 21 Feb 2003 11:40:28 +0100	[thread overview]
Message-ID: <20030221104028.GO31480@x30.school.suse.de> (raw)
In-Reply-To: <20030220212758.5064927f.akpm@digeo.com>

On Thu, Feb 20, 2003 at 09:27:58PM -0800, Andrew Morton wrote:
> 
> Here we look at what affect a large streaming read has upon an operation
> which reads many small files from the same disk.
> 
> A single streaming read was set up with:
> 
> 	while true
> 	do
> 	        cat 512M-file > /dev/null
> 	done
> 
> and we measure how long it takes to read all the files from a 2.4.19 kernel
> tree off the same disk with
> 
> 	time (find kernel-tree -type f | xargs cat > /dev/null)
> 
> 
> 
> 2.4.21-pre4:	31 minutes 30 seconds
> 
> 2.5.61+hacks:	3 minutes 39 seconds
> 
> 2.5.61+CFQ:	5 minutes 7 seconds (*)
> 
> 2.5.61+AS:	17 seconds
> 
> 
> 
> 
> 
> * CFQ performed very strangely here.  Tremendous amount of seeking and a

strangely? this is the *feature*. Benchmarking CFQ in function of real
time is pointless, apparently you don't understand the whole point about
CFQ and you keep benchmarking like if CFQ was designed for a database
workload. the only thing you care if you run CFQ is the worst case
latency of read, never the throughput, 128k/sec is more than enough as
far as you never wait 2 seconds before you can get the next 128k.

take tiobench with 1 single thread in read mode and keep it running in
background and collect the worst case latency, only *then* you will have
a chance to see a benefit. CFQ is all but a generic purpose elevator.
You must never use CFQ if your object is throughput and you benchmark
the global workload and not the worst case latency of every single read
or write-sync syscall.

CFQ is made for multimedia desktop usage only, you want to be sure
mplayer or xmms will never skip frames, not for parallel cp reading
floods of data at max speed like a database with zillon of threads. For
multimedia not to skip frames 1M/sec is  more than enough bandwidth,
doesn't matter if the huge database in background runs much slower as
far as you never skip a frame.

If you don't mind to skip frames you shouldn't use CFQ and everything
will run faster, period.

Andrea

  reply	other threads:[~2003-02-21 10:30 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 ` 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 [this message]
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=20030221104028.GO31480@x30.school.suse.de \
    --to=andrea@suse.de \
    --cc=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