From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Tejun Heo <htejun@gmail.com>
Cc: Jens Axboe <axboe@suse.de>,
James.Bottomley@steeleye.com,
Christoph Hellwig <hch@infradead.org>,
linux-scsi@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH scsi-misc-2.6 01/05] scsi: make blk layer set REQ_SOFTBARRIER when a request is dispatched
Date: Wed, 20 Apr 2005 17:58:19 +1000 [thread overview]
Message-ID: <1113983899.5074.111.camel@npiggin-nld.site> (raw)
In-Reply-To: <20050420074026.GA11228@htj.dyndns.org>
On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
> Hello, Jens.
>
> On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
> > Do it on requeue, please - not on the initial spotting of the request.
>
> This is the reworked version of the patch. It sets REQ_SOFTBARRIER
> in two places - in elv_next_request() on BLKPREP_DEFER and in
> blk_requeue_request().
>
> Other patches apply cleanly with this patch or the original one and
> the end result is the same, so take your pick. :-)
>
I'm not sure that you need *either* one.
As far as I'm aware, REQ_SOFTBARRIER is used when feeding requests
into the top of the block layer, and is used to guarantee the device
driver gets the requests in a specific ordering.
When dealing with the requests at the other end (ie.
elevator_next_req_fn, blk_requeue_request), then ordering does not
change.
That is - if you call elevator_next_req_fn and don't dequeue the
request, then that's the same request you'll get next time.
And blk_requeue_request will push the request back onto the end of
the queue in a LIFO manner.
So I think adding barriers, apart from not doing anything, confuses
the issue because it suggests there *could* be reordering without
them.
Or am I completely wrong? It's been a while since I last got into
the code.
--
SUSE Labs, Novell Inc.
next prev parent reply other threads:[~2005-04-20 7:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 23:15 [PATCH scsi-misc-2.6 00/05] scsi: change REQ_SPECIAL/REQ_SOFTBARRIER usages Tejun Heo
2005-04-19 23:15 ` [PATCH scsi-misc-2.6 01/05] scsi: make blk layer set REQ_SOFTBARRIER when a request is dispatched Tejun Heo
2005-04-20 6:30 ` Jens Axboe
2005-04-20 6:44 ` Tejun Heo
2005-04-20 7:40 ` Tejun Heo
2005-04-20 7:58 ` Nick Piggin [this message]
2005-04-20 8:37 ` Tejun Heo
2005-04-20 8:38 ` Jens Axboe
2005-04-20 9:04 ` Nick Piggin
2005-04-20 9:14 ` Jens Axboe
2005-04-20 9:24 ` Nick Piggin
2005-04-20 9:44 ` Jens Axboe
2005-04-20 22:58 ` Tejun Heo
2005-04-19 23:15 ` [PATCH scsi-misc-2.6 02/05] scsi: remove REQ_SPECIAL in scsi_init_io() Tejun Heo
2005-04-19 23:15 ` [PATCH scsi-misc-2.6 03/05] scsi: make scsi_queue_insert() use blk_requeue_request() Tejun Heo
2005-04-20 23:24 ` James Bottomley
2005-04-21 0:20 ` Tejun Heo
2005-04-21 2:16 ` James Bottomley
2005-04-21 2:29 ` Tejun Heo
2005-04-21 2:43 ` Tejun Heo
2005-04-21 6:10 ` Jens Axboe
2005-04-21 12:45 ` James Bottomley
2005-04-22 11:37 ` Jens Axboe
2005-04-19 23:15 ` [PATCH scsi-misc-2.6 04/05] scsi: make scsi_requeue_request() " Tejun Heo
2005-04-19 23:16 ` [PATCH scsi-misc-2.6 05/05] scsi: remove requeue feature from blk_insert_request() Tejun Heo
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=1113983899.5074.111.camel@npiggin-nld.site \
--to=nickpiggin@yahoo.com.au \
--cc=James.Bottomley@steeleye.com \
--cc=axboe@suse.de \
--cc=hch@infradead.org \
--cc=htejun@gmail.com \
--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®