From: Jens Axboe <jens.axboe@oracle.com>
To: Tejun Heo <tj@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Mike Anderson <andmike@linux.vnet.ibm.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
SCSI development list <linux-scsi@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Problems with the block-layer timeouts
Date: Mon, 3 Nov 2008 18:27:00 +0100 [thread overview]
Message-ID: <20081103172700.GW31673@kernel.dk> (raw)
In-Reply-To: <490F2953.30709@kernel.org>
On Tue, Nov 04 2008, Tejun Heo wrote:
> I'm trying to convert all drivers to use the same command issue model -
> elv_next_request() -> blkdev_dequeue_request() on actual issue ->
> blk_end_request(). I have first draft of the conversion patchset but
> it's gonna take me a few more days to review and test what I can as
> several drivers (mostly legacy ones) are a bit tricky.
Don't do that, please. What we need to do is ensure that the model fits
with whatever the driver wants to do there, and for some drivers it's
actually a lot easier to rely on elv_next_request() returning the same
requests again instead of keeping track of it yourself. So any patch
that enforces the model that you must dequeue before starting the
request, will get a big nak from me.
What we need to do is add a 'peek' mode only, which doesn't start the
request. Along with something to mark it started that the driver can
use, or it can just use elv_next_request() of course.
> For the time being, SCSI layer is the only block layer timeout user and
> completion w/o dequeuing is only for error cases in SCSI, so the
> inefficiency there shouldn't matter too much.
Agree, for now we are ok since it's just SCSI.
--
Jens Axboe
next prev parent reply other threads:[~2008-11-03 17:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-01 16:54 Problems with the block-layer timeouts Alan Stern
2008-11-02 20:35 ` Mike Anderson
2008-11-03 8:52 ` Jens Axboe
2008-11-03 14:18 ` James Smart
2008-11-03 17:23 ` Jens Axboe
2008-11-03 15:59 ` Alan Stern
2008-11-03 16:39 ` Tejun Heo
2008-11-03 17:07 ` Alan Stern
2008-11-03 17:27 ` Jens Axboe [this message]
2008-11-04 3:01 ` Tejun Heo
2008-11-06 0:01 ` FUJITA Tomonori
2008-11-06 7:23 ` Jens Axboe
2008-11-07 4:05 ` FUJITA Tomonori
2008-11-07 11:24 ` Jens Axboe
2008-11-11 6:54 ` FUJITA Tomonori
2008-11-11 17:11 ` Alan Stern
2008-11-11 19:19 ` Jens Axboe
2008-11-12 2:08 ` FUJITA Tomonori
2008-11-13 10:34 ` Jens Axboe
2008-11-17 3:48 ` FUJITA Tomonori
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=20081103172700.GW31673@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andmike@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tj@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