From: Jens Axboe <jens.axboe@oracle.com>
To: Kasper Sandberg <lkml@metanurb.dk>
Cc: Daniel J Blueman <daniel.blueman@gmail.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Matthew <jackdachef@gmail.com>
Subject: Re: performance "regression" in cfq compared to anticipatory, deadline and noop
Date: Tue, 13 May 2008 14:20:21 +0200 [thread overview]
Message-ID: <20080513122021.GP16217@kernel.dk> (raw)
In-Reply-To: <1210514567.7827.62.camel@localhost>
On Sun, May 11 2008, Kasper Sandberg wrote:
> On Sun, 2008-05-11 at 14:14 +0100, Daniel J Blueman wrote:
> > I've been experiencing this for a while also; an almost 50% regression
> > is seen for single-process reads (ie sync) if slice_idle is 1ms or
> > more (eg default of 8) [1], which seems phenomenal.
> >
> > Jens, is this the expected price to pay for optimal busy-spindle
> > scheduling, a design issue, bug or am I missing something totally?
> >
> > Thanks,
> > Daniel
> >
> > --- [1]
> >
> > # cat /sys/block/sda/queue/iosched/slice_idle
> > 8
> > # echo 1 >/proc/sys/vm/drop_caches
> > # dd if=/dev/sda of=/dev/null bs=64k count=5000
> > 5000+0 records in
> > 5000+0 records out
> > 327680000 bytes (328 MB) copied, 4.92922 s, 66.5 MB/s
> >
> > # echo 0 >/sys/block/sda/queue/iosched/slice_idle
> > # echo 1 >/proc/sys/vm/drop_caches
> > # dd if=/dev/sda of=/dev/null bs=64k count=5000
> > 5000+0 records in
> > 5000+0 records out
> > 327680000 bytes (328 MB) copied, 2.74098 s, 120 MB/s
> >
> > # hdparm -Tt /dev/sda
> >
> > /dev/sda:
> > Timing cached reads: 15464 MB in 2.00 seconds = 7741.05 MB/sec
> > Timing buffered disk reads: 342 MB in 3.01 seconds = 113.70 MB/sec
> >
> > [120MB/s is known platter-rate for this disc, so expected]
>
> This appears to be what i get aswell..
>
> root@quadstation # dd if=/dev/sda of=/dev/null bs=64k count=5000
> 5000+0 records in
> 5000+0 records out
> 327680000 bytes (328 MB) copied, 5.48209 s, 59.8 MB/s
> root@quadstation # echo 0 >/sys/block/sda/queue/iosched/slice_idle
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # dd if=/dev/sda of=/dev/null bs=64k count=5000
> 5000+0 records in
> 5000+0 records out
> 327680000 bytes (328 MB) copied, 2.93932 s, 111 MB/s
> root@quadstation # hdparm -Tt /dev/sda
> Timing cached reads: 7264 MB in 2.00 seconds = 3633.82 MB/sec
> Timing buffered disk reads: 322 MB in 3.01 seconds = 107.00 MB/se
> root@quadstation # echo 0 >/sys/block/sda/queue/iosched/slice_idle
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # hdparm -Tt /dev/sda
> Timing cached reads: 15268 MB in 2.00 seconds = 7643.54 MB/sec
> Timing buffered disk reads: 328 MB in 3.01 seconds = 108.85 MB/sec
>
>
> To be sure, i did it all again:
> noop:
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # dd if=/dev/sda of=/dev/null bs=64k count=5000
> 5000+0 records in
> 5000+0 records out
> 327680000 bytes (328 MB) copied, 2.85503 s, 115 MB/s
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # hdparm -tT /dev/sda
> Timing cached reads: 14076 MB in 2.00 seconds = 7045.78 MB/sec
> Timing buffered disk reads: 328 MB in 3.01 seconds = 109.12 MB/sec
>
> anticipatory:
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # dd if=/dev/sda of=/dev/null bs=64k count=5000
> 5000+0 records in
> 5000+0 records out
> 327680000 bytes (328 MB) copied, 2.96948 s, 110 MB/s
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # hdparm -tT /dev/sda
> Timing cached reads: 13424 MB in 2.00 seconds = 6719.29 MB/sec
> Timing buffered disk reads: 328 MB in 3.01 seconds = 109.13 MB/sec
>
> cfq:
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # dd if=/dev/sda of=/dev/null bs=64k count=5000
> 5000+0 records in
> 5000+0 records out
> 327680000 bytes (328 MB) copied, 5.25252 s, 62.4 MB/s
> root@quadstation # echo 1 >/proc/sys/vm/drop_caches
> root@quadstation # hdparm -tT /dev/sda
> Timing cached reads: 13434 MB in 2.00 seconds = 6723.59 MB/sec
> Timing buffered disk reads: 188 MB in 3.00 seconds = 62.57 MB/sec
>
> Thisd would appear to be quite a considerable performance difference.
Indeed, that is of course a bug. The initial mail here mentions this as
a regression - which kernel was the last that worked ok?
If someone would send me a blktrace of such a slow run, that would be
nice. Basically just do a blktrace /dev/sda (or whatever device) while
doing the hdparm, preferably storing output files on a difference
device. Then send the raw sda.blktrace.* files to me. Thanks!
--
Jens Axboe
next prev parent reply other threads:[~2008-05-13 12:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-11 13:14 performance "regression" in cfq compared to anticipatory, deadline and noop Daniel J Blueman
2008-05-11 14:02 ` Kasper Sandberg
2008-05-13 12:20 ` Jens Axboe [this message]
2008-05-13 12:58 ` Matthew
2008-05-13 13:05 ` Jens Axboe
[not found] ` <e85b9d30805130842p3a34305l4ab1e7926e4b0dba@mail.gmail.com>
2008-05-13 18:03 ` Jens Axboe
2008-05-13 18:40 ` Jens Axboe
2008-05-13 19:23 ` Matthew
2008-05-13 19:30 ` Jens Axboe
2008-05-14 8:05 ` Daniel J Blueman
2008-05-14 8:26 ` Jens Axboe
2008-05-14 20:52 ` Daniel J Blueman
2008-05-14 21:37 ` Matthew
2008-05-15 7:01 ` Jens Axboe
2008-05-15 12:21 ` Fabio Checconi
2008-05-16 6:40 ` Jens Axboe
2008-05-16 7:46 ` Fabio Checconi
2008-05-16 7:49 ` Jens Axboe
2008-05-16 7:57 ` Jens Axboe
2008-05-16 8:53 ` Daniel J Blueman
2008-05-16 8:57 ` Jens Axboe
2008-05-16 15:23 ` Matthew
2008-05-16 18:39 ` Fabio Checconi
2008-08-24 20:24 ` Daniel J Blueman
2008-08-25 20:29 ` Fabio Checconi
2008-08-25 15:39 ` Daniel J Blueman
2008-08-25 17:06 ` Fabio Checconi
2008-12-09 15:14 ` Daniel J Blueman
[not found] ` <e85b9d30805140332r3311b2d6r6831d37421ced757@mail.gmail.com>
[not found] ` <e85b9d30805140334q69cb5eacued9a719414e73d53@mail.gmail.com>
[not found] ` <20080514103956.GD16217@kernel.dk>
[not found] ` <e85b9d30805141239g5df9abc6i666b1f621d632b44@mail.gmail.com>
[not found] ` <e85b9d30805161549o7c8f065do24b6567e2ade0afa@mail.gmail.com>
2008-05-19 10:39 ` Matthew
2008-05-13 13:51 ` Kasper Sandberg
2008-05-14 0:33 ` Kasper Sandberg
-- strict thread matches above, loose matches on Subject: below --
2008-05-10 19:18 Matthew
[not found] ` <20080510200053.GA78555@gandalf.sssup.it>
2008-05-10 20:39 ` Matthew
2008-05-10 21:56 ` Fabio Checconi
2008-05-11 0:00 ` Aaron Carroll
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=20080513122021.GP16217@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=daniel.blueman@gmail.com \
--cc=jackdachef@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metanurb.dk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.