From: Dan Aloni <da-x@monatomic.org>
To: Steven Hayter <steven@hayter.me.uk>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>,
linux-scsi@vger.kernel.org, Mike Christie <michaelc@cs.wisc.edu>,
James.Bottomley@steeleye.com
Subject: Re: [PATCH] scsi_execute_async() should add to the tail of the queue
Date: Thu, 21 Dec 2006 09:12:19 +0200 [thread overview]
Message-ID: <458A33D3.6020704@monatomic.org> (raw)
In-Reply-To: <45899FBD.9070803@hayter.me.uk>
Steven Hayter wrote:
> Dan Aloni wrote:
>> Hello,
>>
>> scsi_execute_async() has replaced scsi_do_req() a few versions ago,
>> but it also incurred a change of behavior. I noticed that
>> over-queuing a SCSI device using that function causes I/Os to be
>> starved from low-level queuing for no justified reason.
>>
>> I think it makes much more sense to perserve the original behaviour
>> of scsi_do_req() and add the request to the tail of the queue.
>
> As far as I'm aware the way in which scsi_do_req() was to insert at
> the head of the queue, leading to projects like SCST to come up with
> scsi_do_req_fifo() as queuing multiple commands using scsi_do_req()
> with constant head insertion might lead to out of order execution.
>
> Just thought I'd throw some light on the history and what others have
> done in the past.
>
In Linux 2.4.31 scsi_do_req() still inserts at the tail. This was also
valid until 2.6.5.
James, is the change you inserted in Linux 2.6.5 still relevant in 2.6
today?
<James.Bottomley@steeleye.com>
[PATCH] add device quiescing to the SCSI API
This patch adds the ability to quiesce a SCSI device. The idea
is that
user issued commands (including filesystem ones) would get blocked,
while mid-layer and device issued ones would be allowed to proceed.
This is for things like Domain Validation which like to operate
on an
otherwise quiet device.
There is one big change: to get all of this to happen correctly,
scsi_do_req() has to queue on the *head* of the request queue,
not the
tail as it was doing previously. The reason is that deferred
requests
block the queue, so anything needing executing after a deferred
request
has to go in front of it. I don't think there are any untoward
consequences of this.
--
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
next prev parent reply other threads:[~2006-12-21 7:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 0:02 [PATCH] scsi_execute_async() should add to the tail of the queue Dan Aloni
2006-12-20 20:40 ` Steven Hayter
2006-12-21 7:12 ` Dan Aloni [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-12-19 8:35 Dan Aloni
2006-12-19 10:03 ` Arjan van de Ven
2006-12-19 10:34 ` Dan Aloni
2006-12-20 23:50 ` Jeremy Linton
2006-12-19 11:26 ` Jens Axboe
2006-12-19 18:34 ` Jon Escombe
2006-12-19 18:44 ` 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=458A33D3.6020704@monatomic.org \
--to=da-x@monatomic.org \
--cc=James.Bottomley@steeleye.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=steven@hayter.me.uk \
/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