Re: [PATCH scsi-misc-2.6 01/05] scsi: make blk layer set REQ_SOFTBARRIER when a request is dispatched

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]>

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux