All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kasper Sandberg <lkml@metanurb.dk>
To: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: axboe@kernel.dk, Linux Kernel <linux-kernel@vger.kernel.org>,
	Matthew <jackdachef@gmail.com>
Subject: Re: performance "regression" in cfq compared to anticipatory, deadline and noop
Date: Sun, 11 May 2008 16:02:47 +0200	[thread overview]
Message-ID: <1210514567.7827.62.camel@localhost> (raw)
In-Reply-To: <6278d2220805110614i7160a8a5o36d55acb732c1b59@mail.gmail.com>

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.


  reply	other threads:[~2008-05-11 14:05 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 [this message]
2008-05-13 12:20   ` Jens Axboe
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=1210514567.7827.62.camel@localhost \
    --to=lkml@metanurb.dk \
    --cc=axboe@kernel.dk \
    --cc=daniel.blueman@gmail.com \
    --cc=jackdachef@gmail.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 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.