From: James Bottomley <James.Bottomley@SteelEye.com>
To: James Bottomley <James.Bottomley@SteelEye.com>,
axboe@suse.de, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Proposed changes to generic blk tag for use in SCSI (1/3)
Date: Thu, 13 Jun 2002 17:26:44 -0400 [thread overview]
Message-ID: <200206132126.g5DLQiQ24889@localhost.localdomain> (raw)
In-Reply-To: Message from Doug Ledford <dledford@redhat.com> of "Thu, 13 Jun 2002 17:01:41 EDT." <20020613170141.B4609@redhat.com>
On Mon, Jun 10, 2002 at 10:46:44PM -0400, James Bottomley wrote:
> 2) The SCSI queue will stall if it gets an untagged request in the stream, so
> once tagged queueing is enabled, all commands (including SPECIALS) must be
> tagged. I altered the check in blk_queue_start_tag to permit this.
dledford@redhat.com said:
> Hmmm...this seems broken to me. Switching from tagged to untagged
> momentarily and then back is perfectly valid. Can the bio layer
> handle this and not the scsi layer, or are both layers unable to
> handle this sort of tag manipulation?
The layers can cope with the switch easily enough. The problem is that to
send an untagged command to a SCSI device you have to wait for the outstanding
tags to clear which is what causes the stall. The scsi mid-layer queue push
back system pushes all commands back to the BIO layer marked as REQ_SPECIAL
(because the upper layer drivers generate the commands and it has no idea what
they are supposed to be doing) if the driver cannot handle them. This means
for those drivers (like the new adaptec) which load up the device until it
returns a queue full (thus causing push back into the bio layer) we'd get
stutter in the command pipeline. The cleanest solution is to allow (but not
require) tagging of every request type.
On Mon, Jun 10, 2002 at 10:46:44PM -0400, James Bottomley wrote:
> There are several shortcomings of the prototype, most notably it doesn't have
> tag starvation detection and processing. However, I think I can re-introduce
> this as part of the error handler functions.
dledford@redhat.com said:
> If you are using the bio layer tag processing, then it should be
> doing this part I would think. If it isn't, then it sounds like
> either it's design is missing some key elements required to be fully
> functional or the integration between the scsi layer and the bio
> layer needs some additional work.
I thought about doing this. The problem is that the blk layer doesn't have
very good instrumentation for detecting the condition. The SCSI layer is the
one that has per command timers and all the other necessaries so it can detect
when a command should have returned and take corrective action.
James
next prev parent reply other threads:[~2002-06-13 21:26 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-11 2:46 James Bottomley
2002-06-11 5:50 ` Jens Axboe
2002-06-11 14:29 ` James Bottomley
2002-06-11 14:45 ` Jens Axboe
2002-06-11 16:39 ` James Bottomley
2002-06-13 21:01 ` Doug Ledford
2002-06-13 21:26 ` James Bottomley [this message]
2002-06-13 21:50 ` Doug Ledford
2002-06-13 22:09 ` James Bottomley
2002-09-03 14:35 aic7xxx sets CDR offline, how to reset? James Bottomley
2002-09-03 18:23 ` Doug Ledford
2002-09-03 19:09 ` James Bottomley
2002-09-03 20:59 ` Alan Cox
2002-09-03 21:32 ` James Bottomley
2002-09-03 21:54 ` Alan Cox
2002-09-03 22:50 ` Doug Ledford
2002-09-03 23:28 ` Alan Cox
2002-09-04 7:40 ` Jeremy Higdon
2002-09-04 16:24 ` James Bottomley
2002-09-04 17:13 ` Mike Anderson
2002-09-05 9:50 ` Jeremy Higdon
2002-09-04 16:13 ` James Bottomley
2002-09-04 16:50 ` Justin T. Gibbs
2002-09-05 9:39 ` Jeremy Higdon
2002-09-05 13:35 ` Justin T. Gibbs
2002-09-03 21:13 ` Doug Ledford
2002-09-03 21:48 ` James Bottomley
2002-09-03 22:42 ` Doug Ledford
2002-09-03 22:52 ` Doug Ledford
2002-09-03 23:29 ` Alan Cox
2002-09-04 21:16 ` Luben Tuikov
2002-09-04 10:37 ` Andries Brouwer
2002-09-04 10:48 ` Doug Ledford
2002-09-04 11:23 ` Alan Cox
2002-09-04 16:25 ` Rogier Wolff
2002-09-04 19:34 ` Thunder from the hill
2002-09-03 21:24 ` Patrick Mansfield
2002-09-03 22:02 ` James Bottomley
2002-09-03 23:26 ` Alan Cox
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=200206132126.g5DLQiQ24889@localhost.localdomain \
--to=james.bottomley@steeleye.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®