Tech Insider					     Technology and Trends


			      USENET Archives

Path: archiver1.google.com!news1.google.com!sn-xit-03!sn-xit-01!sn-xit-09!
supernews.com!news.maxwell.syr.edu!news.kiev.sovam.com!Svitonline.COM!
carrier.kiev.ua!not-for-mail
From: Andrew Morton <a...@digeo.com>
Newsgroups: lucky.linux.kernel
Subject: IO scheduler benchmarking
Date: Fri, 21 Feb 2003 05:25:24 +0000 (UTC)
Organization: unknown
Lines: 50
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030220212304.4712fee9.akpm@digeo.com.lucky.linux.kernel>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: horse.lucky.net 1045805125 38667 193.193.193.118 (21 Feb 2003 05:25:25 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Fri, 21 Feb 2003 05:25:25 +0000 (UTC)
X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
X-OriginalArrivalTime: 21 Feb 2003 05:21:26.0457 (UTC) FILETIME=[14DC4A90:01C2D969]
X-Mailing-List: 	linux-kernel@vger.kernel.org


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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IO scheduler benchmarking
From: David Lang (david.lang@digitalinsight.com)
Date: Fri Feb 21 2003 - 01:51:37 EST 

one other useful test would be the time to copy a large (multi-gig) file. 
currently this takes forever and uses very little fo the disk bandwidth, I 
suspect that the AS would give more preference to reads and therefor would 
go faster. 

for a real-world example, mozilla downloads files to a temp directory and 
then copies it to the premanent location. When I download a video from my 
tivo it takes ~20 min to download a 1G video, during which time the system 
is perfectly responsive, then after the download completes when mozilla 
copies it to the real destination (on a seperate disk so it is a copy, not 
just a move) the system becomes completely unresponsive to anything 
requireing disk IO for several min. 

David Lang 

On Thu, 20 Feb 2003, Andrew Morton wrote: 

> Date: Thu, 20 Feb 2003 21:23:04 -0800 
> From: Andrew Morton  
> To: linux-kernel@vger.kernel.org 
> Subject: IO scheduler benchmarking 
> 
> 
> 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. 
> 
> 
> 
> - 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
> the body of a message to majordomo@vger.kernel.org 
> More majordomo info at http://vger.kernel.org/majordomo-info.html 
> Please read the FAQ at http://www.tux.org/lkml/ 
> 
- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in 
the body of a message to majordomo@vger.kernel.org 
More majordomo info at http://vger.kernel.org/majordomo-info.html 
Please read the FAQ at http://www.tux.org/lkml/ 

Path: archiver1.google.com!news2.google.com!news1.google.com!sn-xit-03!
sn-xit-01!sn-xit-06!sn-xit-09!supernews.com!news.maxwell.syr.edu!
news.kiev.sovam.com!Svitonline.COM!carrier.kiev.ua!not-for-mail
From: Andrew Morton <a...@digeo.com>
Newsgroups: lucky.linux.kernel
Subject: Re: IO scheduler benchmarking
Date: Fri, 21 Feb 2003 08:16:57 +0000 (UTC)
Organization: unknown
Lines: 39
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030221001624.278ef232.akpm@digeo.com.lucky.linux.kernel>
References: <20030220212304.4712fee9.akpm@digeo.com>
	<Pine.LNX.4.44.0302202247110.12601-100000@dlang.diginsite.com>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: horse.lucky.net 1045815417 31165 193.193.193.118 (21 Feb 2003 08:16:57 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Fri, 21 Feb 2003 08:16:57 +0000 (UTC)
In-Reply-To: <Pine.LNX.4.44.0302202247110.12601-100000@dlang.diginsite.com>
X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
X-OriginalArrivalTime: 21 Feb 2003 08:14:44.0637 (UTC) FILETIME=[4AA8A4D0:01C2D981]
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: David Lang

David Lang <david.l...@digitalinsight.com> wrote:
>
> one other useful test would be the time to copy a large (multi-gig) file.
> currently this takes forever and uses very little fo the disk bandwidth, I
> suspect that the AS would give more preference to reads and therefor would
> go faster.

Yes, that's a test.

	time (cp 1-gig-file foo ; sync)

2.5.62-mm2,AS:		1:22.36
2.5.62-mm2,CFQ:		1:25.54
2.5.62-mm2,deadline:	1:11.03
2.4.21-pre4:		1:07.69

Well gee.


> for a real-world example, mozilla downloads files to a temp directory and
> then copies it to the premanent location. When I download a video from my
> tivo it takes ~20 min to download a 1G video, during which time the system
> is perfectly responsive, then after the download completes when mozilla
> copies it to the real destination (on a seperate disk so it is a copy, not
> just a move) the system becomes completely unresponsive to anything
> requireing disk IO for several min.

Well 2.4 is unreponsive period.  That's due to problems in the VM - processes
which are trying to allocate memory get continually DoS'ed by `cp' in page
reclaim.

For the reads-starved-by-writes problem which you describe, you'll see that
quite a few of the tests did cover that.  contest does as well.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!
sn-xit-01!sn-xit-08!supernews.com!38.144.126.75.MISMATCH!
feed1.newsreader.com!newsreader.com!news-spur1.maxwell.syr.edu!
news.maxwell.syr.edu!news.kiev.sovam.com!Svitonline.COM!carrier.kiev.ua!
not-for-mail
From: Andrea Arcangeli <and...@suse.de>
Newsgroups: lucky.linux.kernel
Subject: Re: IO scheduler benchmarking
Date: Fri, 21 Feb 2003 10:34:33 +0000 (UTC)
Organization: unknown
Lines: 55
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030221103140.GN31480@x30.school.suse.de.lucky.linux.kernel>
References: 
<20030220212304.4712fee9.akpm@digeo.com> 
<Pine.LNX.4.44.0302202247110.12601-100000@dlang.diginsite.com> 
<20030221001624.278ef232.akpm@digeo.com>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: horse.lucky.net 1045823673 6095 193.193.193.118 (21 Feb 2003 10:34:33 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Fri, 21 Feb 2003 10:34:33 +0000 (UTC)
X-Authentication-Warning: athlon.random: andrea set sender to and...@suse.de using -f
Content-Disposition: inline
In-Reply-To: <20030221001624.278ef232.akpm@digeo.com>
User-Agent: Mutt/1.4i
X-GPG-Key: 1024D/68B9CB43
X-PGP-Key: 1024R/CB4660B9
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: Andrew Morton

On Fri, Feb 21, 2003 at 12:16:24AM -0800, Andrew Morton wrote:
> Yes, that's a test.
> 
> 	time (cp 1-gig-file foo ; sync)
> 
> 2.5.62-mm2,AS:		1:22.36
> 2.5.62-mm2,CFQ:		1:25.54
> 2.5.62-mm2,deadline:	1:11.03
> 2.4.21-pre4:		1:07.69
> 
> Well gee.

It's pointless to benchmark CFQ in a workload like that IMHO. if you
read and write to the same harddisk you want lots of unfariness to go
faster.  Your latency is the mixture of read and writes and the writes
are run by the kernel likely so CFQ will likely generate more seeks (it
also depends if you have the magic for the current->mm == NULL).

You should run something on these lines to measure the difference:

	dd if=/dev/zero of=readme bs=1M count=2000
	sync
	cp /dev/zero . & time cp readme /dev/null

And the best CFQ benchmark really is to run tiobench read test with 1
single thread during the `cp /dev/zero .`. That will measure the worst
case latency that `read` provided during the benchmark, and it should
make the most difference because that is definitely the only thing one
can care about if you need CFQ or SFQ. You don't care that much about
throughput if you enable CFQ, so it's not even correct to even benchmark in
function of real time, but only the worst case `read` latency matters.

> > for a real-world example, mozilla downloads files to a temp directory and
> > then copies it to the premanent location. When I download a video from my
> > tivo it takes ~20 min to download a 1G video, during which time the system
> > is perfectly responsive, then after the download completes when mozilla
> > copies it to the real destination (on a seperate disk so it is a copy, not
> > just a move) the system becomes completely unresponsive to anything
> > requireing disk IO for several min.
> 
> Well 2.4 is unreponsive period.  That's due to problems in the VM - processes
> which are trying to allocate memory get continually DoS'ed by `cp' in page
> reclaim.

this depends on the workload, you may not have that many allocations,
a echo 1 >/proc/sys/vm/bdflush will fix it shall your workload be hurted
by too much dirty cache. Furthmore elevator-lowlatency makes
the blkdev layer much more fair under load.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-03!sn-xit-01!
sn-xit-08!supernews.com!newsfeed.news2me.com!newsfeed.media.kyoto-u.ac.jp!
news2.dg.net.ua!carrier.kiev.ua!not-for-mail
From: rwh...@earthlink.net
Newsgroups: lucky.linux.kernel
Subject: Re: IO scheduler benchmarking
Date: Tue, 25 Feb 2003 05:32:34 +0000 (UTC)
Organization: unknown
Lines: 59
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030225053547.GA1571@rushmore.lucky.linux.kernel>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: horse.lucky.net 1046151154 53658 193.193.193.118 (25 Feb 2003 05:32:34 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 25 Feb 2003 05:32:34 +0000 (UTC)
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: a...@digeo.com

Executive question: Why does 2.5.62-mm2 have higher sequential
write latency than 2.5.61-mm1?

tiobench numbers on uniprocessor single disk IDE:
The cfq scheduler (2.5.62-mm2 and 2.5.61-cfq) has a big latency
regression.

2.5.61-mm1		(default scheduler (anticipatory?))
2.5.61-mm1-cfq		elevator=cfq
2.5.62-mm2-as		anticipatory scheduler
2.5.62-mm2-dline	elevator=deadline
2.5.62-mm2		elevator=cfq

                    Thr  MB/sec   CPU%     avg lat      max latency
2.5.61-mm1            8   15.68   54.42%     5.87 ms     2.7 seconds
2.5.61-mm1-cfq        8    9.60   15.07%     7.54      393.0
2.5.62-mm2-as         8   14.76   52.04%     6.14        4.5
2.5.62-mm2-dline      8    9.91   13.90%     9.41         .8
2.5.62-mm2            8    9.83   15.62%     7.38      408.9
2.4.21-pre3           8   10.34   27.66%     8.80        1.0
2.4.21-pre3-ac4       8   10.53   28.41%     8.83         .6
2.4.21-pre3aa1        8   18.55   71.95%     3.25       87.6


For most thread counts (8 - 128), the anticipatory scheduler has roughly 
45% higher ext2 sequential read throughput.  Latency was higher than 
deadline, but a lot lower than cfq.

For tiobench sequential writes, the max latency numbers for 2.4.21-pre3
are notably lower than 2.5.62-mm2 (but not as good as 2.5.61-mm1).  
This is with 16 threads.  

                    Thr  MB/sec   CPU%      avg lat     max latency
2.5.61-mm1           16   18.30   81.12%     9.159 ms     6.1 seconds
2.5.61-mm1-cfq       16   18.03   80.71%     9.086        6.1
2.5.62-mm2-as        16   18.84   84.25%     8.620       47.7
2.5.62-mm2-dline     16   18.53   84.10%     8.967       53.4
2.5.62-mm2           16   18.46   83.28%     8.521       40.8
2.4.21-pre3          16   16.20   65.13%     9.566        8.7
2.4.21-pre3-ac4      16   18.50   83.68%     8.774       11.6
2.4.21-pre3aa1       16   18.49   88.10%     8.455        7.5

Recent uniprocessor benchmarks:
http://home.earthlink.net/~rwhron/kernel/latest.html

More uniprocessor benchmarks:
http://home.earthlink.net/~rwhron/kernel/k6-2-475.html

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html
latest quad xeon benchmarks:
http://home.earthlink.net/~rwhron/kernel/blatest.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-04!
sn-xit-06!sn-xit-08!supernews.com!64.152.100.70.MISMATCH!sjc70.webusenet.com!
c03.atl99!news.webusenet.com!diablo.voicenet.com!news.kiev.sovam.com!
Svitonline.COM!carrier.kiev.ua!not-for-mail
From: Andrew Morton <a...@digeo.com>
Newsgroups: lucky.linux.kernel
Subject: Re: IO scheduler benchmarking
Date: Tue, 25 Feb 2003 06:42:58 +0000 (UTC)
Organization: unknown
Lines: 58
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030224223858.52c61880.akpm@digeo.com.lucky.linux.kernel>
References: <20030225053547.GA1571@rushmore>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: horse.lucky.net 1046155378 86185 193.193.193.118 (25 Feb 2003 06:42:58 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 25 Feb 2003 06:42:58 +0000 (UTC)
In-Reply-To: <20030225053547.GA1571@rushmore>
X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
X-OriginalArrivalTime: 25 Feb 2003 06:38:35.0872 (UTC) FILETIME=[85DBF600:01C2DC98]
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: rwh...@earthlink.net

rwh...@earthlink.net wrote:
>
> Executive question: Why does 2.5.62-mm2 have higher sequential
> write latency than 2.5.61-mm1?

Well bear in mind that we sometimes need to perform reads to be able to
perform writes.  So the way tiobench measures it, you could be seeing
read-vs-write latencies here.

And there are various odd interactions in, at least, ext3.  You did not
specify which filesystem was used.

>  ...
>                     Thr  MB/sec   CPU%     avg lat      max latency
> 2.5.62-mm2-as         8   14.76   52.04%     6.14        4.5
> 2.5.62-mm2-dline      8    9.91   13.90%     9.41         .8
> 2.5.62-mm2            8    9.83   15.62%     7.38      408.9

Fishiness.  2.5.62-mm2 _is_ 2.5.62-mm2-as.  Why the 100x difference?

That 408 seconds looks suspect.


I don't know what tiobench is doing in there, really.  I find it more useful
to test simple things, which I can understand.  If you want to test write
latency, do this:

	while true
	do
		write-and-fsync -m 200 -O -f foo
	done

Maybe run a few of these.  This command will cause a continuous streaming
file overwrite.


then do:

	time write-and-fsync -m1 -f foo

this will simply write a megabyte file, fsync it and exit.

You need to be careful with this - get it wrong and most of the runtime is
actually paging the executables back in.  That is why the above background
load is just reusing the same pagecache over and over.

The latency which I see for the one megabyte write and fsync varies a lot. 
From one second to ten.  That's with the deadline scheduler.

There is a place in VFS where one writing task could accidentally hammer a
different one.  I cannot trigger that, but I'll fix it up in next -mm.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!
sn-xit-09!supernews.com!news.maxwell.syr.edu!news.kiev.sovam.com!
Svitonline.COM!carrier.kiev.ua!not-for-mail
From: rwh...@earthlink.net
Newsgroups: lucky.linux.kernel
Subject: Re: IO scheduler benchmarking
Date: Tue, 25 Feb 2003 12:55:36 +0000 (UTC)
Organization: unknown
Lines: 48
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030225125942.GA1657@rushmore.lucky.linux.kernel>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: horse.lucky.net 1046177736 89618 193.193.193.118 (25 Feb 2003 12:55:36 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 25 Feb 2003 12:55:36 +0000 (UTC)
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: a...@digeo.com

>> Why does 2.5.62-mm2 have higher sequential
>> write latency than 2.5.61-mm1?

> And there are various odd interactions in, at least, ext3.  You did not
> specify which filesystem was used.

ext2

>>                     Thr  MB/sec   CPU%     avg lat      max latency
>> 2.5.62-mm2-as         8   14.76   52.04%     6.14        4.5
>> 2.5.62-mm2-dline      8    9.91   13.90%     9.41         .8
>> 2.5.62-mm2            8    9.83   15.62%     7.38      408.9

> Fishiness.  2.5.62-mm2 _is_ 2.5.62-mm2-as.  Why the 100x difference?

Bad EXTRAVERSION naming on my part.  2.5.62-mm2 _was_ booted with 
elevator=cfq.

How it happened:
2.5.61-mm1 tested
2.5.61-mm1-cfq tested and elevator=cfq added to boot flags
2.5.62-mm1 tested (elevator=cfq still in lilo boot boot flags)
Then to test the other two schedulers I changed extraversion and boot
flags.

> That 408 seconds looks suspect.

AFAICT, that's the one request in over 500,000 that took the longest.
The numbers are fairly consistent.  How relevant they are is debatable.  

> If you want to test write latency, do this:

Your approach is more realistic than tiobench.  

> There is a place in VFS where one writing task could accidentally hammer a
> different one.  I cannot trigger that, but I'll fix it up in next -mm.

2.5.62-mm3 or 2.5.63-mm1?  (-mm3 is running now)

-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!
sn-xit-06!sn-xit-09!supernews.com!news.maxwell.syr.edu!news.kiev.sovam.com!
Svitonline.COM!carrier.kiev.ua!not-for-mail
From: Andrew Morton <a...@digeo.com>
Newsgroups: lucky.linux.kernel
Subject: Re: IO scheduler benchmarking
Date: Tue, 25 Feb 2003 22:24:09 +0000 (UTC)
Organization: unknown
Lines: 43
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <20030225140918.197dea73.akpm@digeo.com.lucky.linux.kernel>
References: <20030225125942.GA1657@rushmore>
NNTP-Posting-Host: horse.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Trace: horse.lucky.net 1046211849 26574 193.193.193.118 (25 Feb 2003 22:24:09 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 25 Feb 2003 22:24:09 +0000 (UTC)
In-Reply-To: <20030225125942.GA1657@rushmore>
X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
X-OriginalArrivalTime: 25 Feb 2003 22:12:26.0275 (UTC) FILETIME=[FA94F730:01C2DD1A]
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: rwh...@earthlink.net

rwh...@earthlink.net wrote:
>
> >> Why does 2.5.62-mm2 have higher sequential
> >> write latency than 2.5.61-mm1?
> 
> > And there are various odd interactions in, at least, ext3.  You did not
> > specify which filesystem was used.
> 
> ext2
> 
> >>                     Thr  MB/sec   CPU%     avg lat      max latency
> >> 2.5.62-mm2-as         8   14.76   52.04%     6.14        4.5
> >> 2.5.62-mm2-dline      8    9.91   13.90%     9.41         .8
> >> 2.5.62-mm2            8    9.83   15.62%     7.38      408.9
> 
> > Fishiness.  2.5.62-mm2 _is_ 2.5.62-mm2-as.  Why the 100x difference?
> 
> Bad EXTRAVERSION naming on my part.  2.5.62-mm2 _was_ booted with 
> elevator=cfq.
> 
> ...
> > That 408 seconds looks suspect.
> 
> AFAICT, that's the one request in over 500,000 that took the longest.
> The numbers are fairly consistent.  How relevant they are is debatable.  

OK.  When I was testing CFQ I saw some odd behaviour, such as a 100%
cessation of reads for periods of up to ten seconds.

So there is some sort of bug in there, and until that is understood we should
not conclude anything at all about CFQ from this testing.

> 2.5.62-mm3 or 2.5.63-mm1?  (-mm3 is running now)

Well I'm showing about seven more AS patches since 2.5.63-mm1 already, so
this is a bit of a moving target.  Sorry.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-owner+fa.linux.kernel=40ifi.uio...@vger.kernel.org>
Original-Date: 	Tue, 25 Feb 2003 16:57:55 -0500
To: linux-ker...@vger.kernel.org
Cc: a...@digeo.com
Subject: Re: IO scheduler benchmarking
Original-Message-ID: <20030225215755.GA2038@rushmore>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
From: rwh...@earthlink.net
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 25 Feb 2003 23:57:35 GMT
Message-ID: <fa.f4nsjj8.1u2ms8g@ifi.uio.no>
Lines: 72

> Why does 2.5.62-mm2 have higher sequential
> write latency than 2.5.61-mm1?

Anticipatory scheduler tiobench profile on uniprocessor:

                              2.5.61-mm1   2.5.62-mm2
total                           1993387     1933241
default_idle                    1873179     1826650
system_call                       49838       43036
get_offset_tsc                    21905       20883
do_schedule                       13893       10344
do_gettimeofday                    8478        6044
sys_gettimeofday                   8077        5153
current_kernel_time                4904       12165
syscall_exit                       4047        1243
__wake_up                          1274        1000
io_schedule                        1166        1039
prepare_to_wait                    1093         792
schedule_timeout                    612         366
delay_tsc                           502         443
get_fpu_cwd                         473         376
syscall_call                        389         378
math_state_restore                  354         271
restore_fpu                         329         287
del_timer                           325         200
device_not_available                290         377
finish_wait                         257         181
add_timer                           218         137
io_schedule_timeout                 195          72
cpu_idle                            193         218
run_timer_softirq                   137          33
remove_wait_queue                   121         188
eligible_child                      106         154
sys_wait4                           105         162
work_resched                        104         110
ret_from_intr                        97          74
dup_task_struct                      75          48
add_wait_queue                       67         124
__cond_resched                       59          69
do_page_fault                        55           0
do_softirq                           53          12
pte_alloc_one                        51          67
release_task                         44          55
get_signal_to_deliver                38          43
get_wchan                            16          10
mod_timer                            15           0
old_mmap                             14          19
prepare_to_wait_exclusive            10          32
mm_release                            7           0
release_x86_irqs                      7           8
sys_getppid                           6           5
handle_IRQ_event                      4           0
schedule_tail                         4           0
kill_proc_info                        3           0
device_not_available_emulate          2           0
task_prio                             1           1
__down                                0          33
__down_failed_interruptible           0           3
init_fpu                              0          12
pgd_ctor                              0           3
process_timeout                       0           2
restore_all                           0           2
sys_exit                              0           2
-- 
Randy Hron
http://home.earthlink.net/~rwhron/kernel/bigbox.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/