From: Nick Piggin <piggin@cyberone.com.au>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: Jens Axboe <axboe@suse.de>,
linux-lvm@sistina.com, linux-kernel@vger.kernel.org,
Joe Thornber <thornber@redhat.com>
Subject: [linux-lvm] Re: IO scheduler, queue depth, nr_requests
Date: Thu Feb 19 09:00:00 2004 [thread overview]
Message-ID: <403418FA.2070202@cyberone.com.au> (raw)
In-Reply-To: <20040219015207.GC30621@drinkel.cistron.nl>
Miquel van Smoorenburg wrote:
>On Thu, 19 Feb 2004 02:24:31, Nick Piggin wrote:
>
>>Miquel van Smoorenburg wrote:
>>
>>
>>>I found out what causes this. It's get_request_wait().
>>>
>>>When the request queue is full, and a new request needs to be created,
>>>__make_request() blocks in get_request_wait().
>>>
>>>Another process wakes up first (pdflush / process submitting I/O itself /
>>>xfsdatad / etc) and sends the next bio's to __make_request().
>>>In the mean time some free requests have become available, and the bios
>>>are merged into a new request. Those requests are submitted to the device.
>>>
>>>Then, get_request_wait() returns but the bio is not mergeable anymore -
>>>and that results in a backwards seek, severely limiting the I/O rate.
>>>
>>>
>>The "batching" logic there should allow a process to submit
>>a number of requests even above the nr_requests limit to
>>prevent this interleave and context switching.
>>
>>Are you using tagged command queueing? What depth?
>>
>
>No, I'm not using tagged command queueing. The 3ware controller is not a
>real scsi controller, the driver just emulates one. It's a raid5 controller
>that drives SATA disks. It has an internal request queue ("can_queu")
>of 254 outstanding commands.
>
This is what I mean by tagged command queueing.
> Because that is way bigger than nr_requests
>this happens - if I set nr_requests to 512, the problem goes away. But
>that shouldn't happen ;)
>
>
What shouldn't happen?
>I'm preparing a proof-of-concept patch now, if it works and I don't wedge
>the remote machine I'm testing this on I'll post it in a few minutes.
>
>
I'm not very happy with forcing a process to sleep _after_ it
has submitted a request... but I'd be interested to see exactly
what your patch does.
By far the best option is to use appropriately sized queues.
The below patch is a start, but it unfortunately doesn't help
drivers which use private queueing implementations.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-mm1/broken-out/scale-nr_requests.patch
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <piggin@cyberone.com.au>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: Jens Axboe <axboe@suse.de>,
linux-lvm@sistina.com, linux-kernel@vger.kernel.org,
Joe Thornber <thornber@redhat.com>
Subject: Re: IO scheduler, queue depth, nr_requests
Date: Thu, 19 Feb 2004 13:01:30 +1100 [thread overview]
Message-ID: <403418FA.2070202@cyberone.com.au> (raw)
In-Reply-To: <20040219015207.GC30621@drinkel.cistron.nl>
Miquel van Smoorenburg wrote:
>On Thu, 19 Feb 2004 02:24:31, Nick Piggin wrote:
>
>>Miquel van Smoorenburg wrote:
>>
>>
>>>I found out what causes this. It's get_request_wait().
>>>
>>>When the request queue is full, and a new request needs to be created,
>>>__make_request() blocks in get_request_wait().
>>>
>>>Another process wakes up first (pdflush / process submitting I/O itself /
>>>xfsdatad / etc) and sends the next bio's to __make_request().
>>>In the mean time some free requests have become available, and the bios
>>>are merged into a new request. Those requests are submitted to the device.
>>>
>>>Then, get_request_wait() returns but the bio is not mergeable anymore -
>>>and that results in a backwards seek, severely limiting the I/O rate.
>>>
>>>
>>The "batching" logic there should allow a process to submit
>>a number of requests even above the nr_requests limit to
>>prevent this interleave and context switching.
>>
>>Are you using tagged command queueing? What depth?
>>
>
>No, I'm not using tagged command queueing. The 3ware controller is not a
>real scsi controller, the driver just emulates one. It's a raid5 controller
>that drives SATA disks. It has an internal request queue ("can_queu")
>of 254 outstanding commands.
>
This is what I mean by tagged command queueing.
> Because that is way bigger than nr_requests
>this happens - if I set nr_requests to 512, the problem goes away. But
>that shouldn't happen ;)
>
>
What shouldn't happen?
>I'm preparing a proof-of-concept patch now, if it works and I don't wedge
>the remote machine I'm testing this on I'll post it in a few minutes.
>
>
I'm not very happy with forcing a process to sleep _after_ it
has submitted a request... but I'd be interested to see exactly
what your patch does.
By far the best option is to use appropriately sized queues.
The below patch is a start, but it unfortunately doesn't help
drivers which use private queueing implementations.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-mm1/broken-out/scale-nr_requests.patch
next prev parent reply other threads:[~2004-02-19 2:02 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
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 [this message]
2004-02-19 9:00 ` 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=403418FA.2070202@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@redhat.com \
--cc=linux-lvm@sistina.com \
--cc=miquels@cistron.nl \
--cc=thornber@redhat.com \
/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.