On Mon, Feb 22, 2010 at 3:49 PM, Mark Lord <kernel@xxxxxxxxxxxx> wrote: > 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? Yeah, that seems like a rather fragile heuristic to me.. -- 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