On 02/22/10 14:05, Jens Axboe wrote:
--- a/block/blk-core.c
+++ b/block/blk-core.c
...
@@ -1857,8 +1857,15 @@ void blk_dequeue_request(struct request *rq)
* and to it is freed is accounted as io that is in progress at
* the driver side.
*/
- if (blk_account_rq(rq))
+ if (blk_account_rq(rq)) {
q->in_flight[rq_is_sync(rq)]++;
+ /*
+ * Mark this device as supporting hardware queuing, if
+ * we have more IOs in flight than 4.
+ */
+ if (!blk_queue_queuing(q) && queue_in_flight(q) > 4)
+ set_bit(QUEUE_FLAG_CQ, &q->queue_flags);
+ }
}
...
Mmm.. So is this code actually trying to rely upon the software being quick
enough to queue five or more commands before the drive completes one of them?
Wouldn't a better way be to just look at the queue_depth, for SCSI/SATA at least?
-ml
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
