From: Jens Axboe <axboe@suse.de>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: Andrew Morton <akpm@osdl.org>,
linux-lvm@sistina.com, linux-kernel@vger.kernel.org,
thornber@redhat.com
Subject: Re: IO scheduler, queue depth, nr_requests
Date: Thu, 19 Feb 2004 11:19:15 +0100 [thread overview]
Message-ID: <20040219101915.GJ27190@suse.de> (raw)
In-Reply-To: <20040219101519.GG30621@drinkel.cistron.nl>
On Thu, Feb 19 2004, Miquel van Smoorenburg wrote:
> On Thu, 19 Feb 2004 03:26:28, Andrew Morton wrote:
> > Miquel van Smoorenburg <miquels@cistron.nl> wrote:
> > >
> > > The thing is, the bio's are submitted perfectly sequentially. It's just that
> > > every so often a request (with just its initial bio) gets stuck for a while.
> > > Because the bio's after it are merged and sent to the device, it's not
> > > possible to merge that stuck request later on when it gets unstuck, because
> > > the other bio's have already left the building so to speak.
> >
> > Oh. So the raid controller's queue depth is larger than the kernel's. So
> > everything gets immediately shovelled into the device and the kernel is
> > left with nothing to merge the little request against.
>
> Well, the request queue of the kernel is max'ed out too, otherwise
> get_request_wait() wouldn't be called. It's just an unfortunate timing
> issue.
Indeed
> > Shouldn't the controller itself be performing the insertion?
>
> Well, you would indeed expect the 3ware hardware to be smarter than
> that, but in its defence, the driver doesn't set sdev->simple_tags or
> sdev->ordered_tags at all. It just has a large queue on the host, in
> hardware.
A too large queue. IMHO the simple and correct solution to your problem
is to diminish the host queue (sane solution), or bump the block layer
queue size (dumb solution).
> Perhaps this info should be exported into the request queue of the device,
> so that ll_rw_blk knows about this and can do something similar to the
> hack I posted ?
>
> Note that AFAICS nothing in drivers/scsi uses the tagging stuff in
> ll_rw_blk.c. blk_queue_init_tags() is only called by
> scsi_activate_tcq(), and nothing ever calls that (except the 53c700.c
> driver). So you can't just check for QUEUE_FLAG_QUEUED. Hmm, nothing
> in drivers/block calls it either. It's not being used at all yet ? Or
> am I being dense ?
No you are correct, I already outlined that to you explicitly in the
very first mail in this thread. Hopefully this will change with 2.7 so
we have some block layer control over tagging in general.
--
Jens Axboe
next prev parent reply other threads:[~2004-02-19 10:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040216131609.GA21974@cistron.nl>
[not found] ` <20040216133047.GA9330@suse.de>
[not found] ` <20040217145716.GE30438@traveler.cistron.net>
2004-02-18 23:52 ` IO scheduler, queue depth, nr_requests Miquel van Smoorenburg
2004-02-19 1:24 ` Nick Piggin
2004-02-19 1:52 ` Miquel van Smoorenburg
2004-02-19 2:01 ` Nick Piggin
2004-02-19 1:26 ` Andrew Morton
2004-02-19 2:11 ` Miquel van Smoorenburg
2004-02-19 2:26 ` Andrew Morton
2004-02-19 10:15 ` Miquel van Smoorenburg
2004-02-19 10:19 ` Jens Axboe [this message]
2004-02-19 20:59 ` Miquel van Smoorenburg
2004-02-19 22:52 ` Nick Piggin
2004-02-19 23:53 ` Miquel van Smoorenburg
2004-02-20 0:15 ` Nick Piggin
2004-02-20 1:12 ` [PATCH] per process request limits (was Re: IO scheduler, queue depth, nr_requests) Nick Piggin
2004-02-20 1:26 ` Andrew Morton
2004-02-20 1:40 ` Nick Piggin
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-20 14:57 ` Jens Axboe
2004-02-20 14:59 ` Joe Thornber
2004-02-20 15:00 ` Jens Axboe
2004-02-22 14:02 ` Miquel van Smoorenburg
2004-02-22 19:55 ` Andrew Morton
2004-02-20 1:45 ` [PATCH] per process request limits (was Re: IO scheduler, queue depth, nr_requests) Nick Piggin
2004-02-19 2:51 ` IO scheduler, queue depth, nr_requests Nick Piggin
2004-02-19 10:21 ` Jens Axboe
[not found] <1qJVx-75K-15@gated-at.bofh.it>
[not found] ` <1qJVx-75K-17@gated-at.bofh.it>
[not found] ` <1qJVw-75K-11@gated-at.bofh.it>
[not found] ` <1qLb8-6m-27@gated-at.bofh.it>
[not found] ` <1qLXl-XV-17@gated-at.bofh.it>
[not found] ` <1qMgF-1dA-5@gated-at.bofh.it>
[not found] ` <1qTs3-7A2-51@gated-at.bofh.it>
[not found] ` <1qTBB-7Hh-7@gated-at.bofh.it>
[not found] ` <1r3AS-1hW-5@gated-at.bofh.it>
[not found] ` <1r5jD-2RQ-31@gated-at.bofh.it>
[not found] ` <1r6fH-3L8-11@gated-at.bofh.it>
[not found] ` <1r6S4-6cv-1@gated-at.bofh.it>
2004-02-25 20:17 ` Bill Davidsen
2004-02-25 21:39 ` Miquel van Smoorenburg
2004-02-26 0:39 ` Nick Piggin
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=20040219101915.GJ27190@suse.de \
--to=axboe@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox