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/
