public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jens Axboe <axboe@suse.de>
Cc: James.Bottomley@steeleye.com,
	Christoph Hellwig <hch@infradead.org>,
	linux-scsi@vger.kernel.org, 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 15:44:44 +0900	[thread overview]
Message-ID: <4265FA5C.8030801@gmail.com> (raw)
In-Reply-To: <20050420063009.GB9371@suse.de>

Jens Axboe wrote:
> On Wed, Apr 20 2005, Tejun Heo wrote:
> 
>>01_scsi_blk_make_started_requests_ordered.patch
>>
>>	Reordering already started requests is without any real
>>	benefit and causes problems if the request has its
>>	driver-specific resources allocated (as in SCSI).  This patch
>>	makes elv_next_request() set REQ_SOFTBARRIER automatically
>>	when a request is dispatched.
>>
>>	As both as and cfq schedulers don't allow passing requeued
>>	requests, the only behavior change is that requests deferred
>>	by prep_fn won't be passed by other requests.  This change
>>	shouldn't cause any problem.  The only affected driver other
>>	than SCSI is i2o_block.
>>
>>Signed-off-by: Tejun Heo <htejun@gmail.com>
>>
>> elevator.c |    8 ++++----
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>>Index: scsi-reqfn-export/drivers/block/elevator.c
>>===================================================================
>>--- scsi-reqfn-export.orig/drivers/block/elevator.c	2005-04-20 08:13:01.000000000 +0900
>>+++ scsi-reqfn-export/drivers/block/elevator.c	2005-04-20 08:13:33.000000000 +0900
>>@@ -370,11 +370,11 @@ struct request *elv_next_request(request
>> 
>> 	while ((rq = __elv_next_request(q)) != NULL) {
>> 		/*
>>-		 * just mark as started even if we don't start it, a request
>>-		 * that has been delayed should not be passed by new incoming
>>-		 * requests
>>+		 * just mark as started even if we don't start it.
>>+		 * also, as a request that has been delayed should not
>>+		 * be passed by new incoming requests, set softbarrier.
>> 		 */
>>-		rq->flags |= REQ_STARTED;
>>+		rq->flags |= REQ_STARTED | REQ_SOFTBARRIER;
>> 
>> 		if (rq == q->last_merge)
>> 			q->last_merge = NULL;
> 
> 
> Do it on requeue, please - not on the initial spotting of the request.
> 

  The thing is that we also need to set REQ_SOFTBARRIER on 
BLKPREP_DEFER.  So, it will be two places - in elv_next_request and 
blk_requeue_request.  The end result will be the same.  Do you think 
doing on requeue paths is better?

-- 
tejun


  reply	other threads:[~2005-04-20  6:44 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 [this message]
2005-04-20  7:40     ` Tejun Heo
2005-04-20  7:58       ` Nick Piggin
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=4265FA5C.8030801@gmail.com \
    --to=htejun@gmail.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=axboe@suse.de \
    --cc=hch@infradead.org \
    --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