All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: linux-lvm@redhat.com
Cc: Miquel van Smoorenburg <miquels@cistron.nl>
Subject: Re: [linux-lvm] Re: IO scheduler, queue depth, nr_requests
Date: Tue Feb 17 01:46:02 2004	[thread overview]
Message-ID: <4031B8F2.7080306@backtobasicsmgmt.com> (raw)
In-Reply-To: <20040216133047.GA9330@suse.de>

Jens Axboe wrote:

>>By fiddling about today I just found that changing
>>/sys/block/sda/queue/nr_requests from 128 to something above
>>the queue depth of the 3ware controller (256 doesn't work,
>>384 and up do) also fixes the problem.

OK, I have run three sets of bonnie++ tests on my system. This was using 
the 2.6-bk kernel as of about midnight GMT of 2004-02-17.

System is single P4HT 2.8GHz (SMP kernel), 1GB RAM (4GB highmem 
enabled), Intel 865G chipset, 3ware 8506-8 with six Seagate 160GB 
Barracuda SATA disks in a single RAID-5. bonnie++ tests run on an XFS 
filesystem (made with default mkfs.xfs parameters using a recent 
xfstools package) over a 200GB LVM2 volume (dm-linear).

bonnie++ -r 512 -s 40960 -f -b

Anticipatory scheduler, nr_requests=128 (default)

Seq. Write   53772
Rand. Write  15557
Seq. Read    47730
Rand. Seek   146.5

Anticipatory scheduler, nr_requests=384

Seq. Write   53843
Rand. Write  17595
Seq. Read    44663
Rand. Seek   143.1

Deadline scheduler, nr_requests=384

Seq. Write   54973
Rand. Write  18897
Seq. Read    41476
Rand. Seek   227.3 (!)

Miquel's suggestion has a definite positive effect, except on sequential 
reads. This system still doesn't produce anywhere near the throughput 
I'd expect though, and still doesn't come close to 2.4 numbers either 
(but those are somewhat bogus, as they rely on setting extremely large 
readahead settings). There may be some sort of hardware problem that is 
limiting me to ~60MB/s, although with 2.4 I was able to get sequential 
read numbers around 95MB/s, so I think the hardware is OK.

  parent reply	other threads:[~2004-02-17  6:47 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-16  9:11 [linux-lvm] IO scheduler, queue depth, nr_requests Miquel van Smoorenburg
2004-02-16  8:30 ` [linux-lvm] " Jens Axboe
2004-02-16  9:01   ` Joe Thornber
2004-02-16 19:32   ` Kevin P. Fleming
2004-02-17  1:46   ` Kevin P. Fleming [this message]
2004-02-18 10:29   ` Miquel van Smoorenburg
2004-02-18 23:52     ` Miquel van Smoorenburg
2004-02-19  8:51       ` [linux-lvm] " Miquel van Smoorenburg
2004-02-19  1:24       ` Nick Piggin
2004-02-19  8:51         ` [linux-lvm] " Nick Piggin
2004-02-19  1:52         ` Miquel van Smoorenburg
2004-02-19  9:00           ` [linux-lvm] " Miquel van Smoorenburg
2004-02-19  2:01           ` Nick Piggin
2004-02-19  9:00             ` [linux-lvm] " Nick Piggin
2004-02-19  1:26       ` Andrew Morton
2004-02-19  8:50         ` [linux-lvm] " Andrew Morton
2004-02-19  2:11         ` Miquel van Smoorenburg
2004-02-19  9:08           ` [linux-lvm] " Miquel van Smoorenburg
2004-02-19  2:26           ` Andrew Morton
2004-02-19  9:08             ` [linux-lvm] " Andrew Morton
2004-02-19 10:15             ` Miquel van Smoorenburg
2004-02-19 10:23               ` [linux-lvm] " Miquel van Smoorenburg
2004-02-19 10:19               ` Jens Axboe
2004-02-19 10:26                 ` [linux-lvm] " Jens Axboe
2004-02-19 15:58                 ` Miquel van Smoorenburg
2004-02-19 20:59                   ` Miquel van Smoorenburg
2004-02-19 17:52                   ` [linux-lvm] " Nick Piggin
2004-02-19 22:52                     ` Nick Piggin
2004-02-19 18:52                     ` [linux-lvm] " Miquel van Smoorenburg
2004-02-19 23:53                       ` Miquel van Smoorenburg
2004-02-19 19:15                       ` [linux-lvm] " Nick Piggin
2004-02-20  0:15                         ` Nick Piggin
2004-02-19 20:16                       ` [linux-lvm] [PATCH] per process request limits (was Re: IO scheduler, queue depth, nr_requests) Nick Piggin
2004-02-20  1:12                         ` Nick Piggin
2004-02-19 20:25                         ` [linux-lvm] " Andrew Morton
2004-02-20  1:26                           ` Andrew Morton
2004-02-19 20:40                           ` [linux-lvm] " Nick Piggin
2004-02-20  1:40                             ` Nick Piggin
2004-02-19 21:32                             ` [linux-lvm] " Andrew Morton
2004-02-20  2:32                               ` Andrew Morton
2004-02-20 14:40                               ` [PATCH] bdi_congestion_funp (was: Re: [PATCH] per process request limits (was Re: IO scheduler, queue depth, nr_requests)) Miquel van Smoorenburg
2004-02-23  8:41                                 ` [linux-lvm] " Miquel van Smoorenburg
2004-02-20  9:56                                 ` [linux-lvm] " Joe Thornber
2004-02-20 14:59                                   ` Joe Thornber
2004-02-20  9:59                                   ` [linux-lvm] " Jens Axboe
2004-02-20 15:00                                     ` Jens Axboe
2004-02-22 14:02                                     ` Miquel van Smoorenburg
2004-02-23  8:45                                       ` [linux-lvm] " Miquel van Smoorenburg
2004-02-22 14:55                                       ` Andrew Morton
2004-02-22 19:55                                         ` Andrew Morton
2004-02-20  9:57                                 ` [linux-lvm] " Jens Axboe
2004-02-20 14:57                                   ` Jens Axboe
2004-02-24 12:54                                   ` [linux-lvm] Queue congestion: passing down vs passing up [PATCH] Miquel van Smoorenburg
2004-02-19 20:52                         ` [linux-lvm] Re: [PATCH] per process request limits (was Re: IO scheduler, queue depth, nr_requests) Nick Piggin
2004-02-20  1:45                           ` Nick Piggin
2004-02-19  2:51           ` IO scheduler, queue depth, nr_requests Nick Piggin
2004-02-19  9:11             ` [linux-lvm] " Nick Piggin
2004-02-19 10:21             ` Jens Axboe
2004-02-19 10:26               ` [linux-lvm] " Jens Axboe

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=4031B8F2.7080306@backtobasicsmgmt.com \
    --to=kpfleming@backtobasicsmgmt.com \
    --cc=linux-lvm@redhat.com \
    --cc=miquels@cistron.nl \
    /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.