On Mon, Feb 22 2010, Robert Hancock wrote:
> 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?
Yes, it'll trigger easily. If it's the boot drive, it'll be on before
booting has completed.
> > 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..
It may seem fragile, but it's not. Queue depth is device information
that isn't available at the block level.
--
Jens Axboe
--
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
