All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.