Re: bad performance with SSD since kernel version 2.6.32

[Robert Hancock <hancockrwd@gmail.com>]

On Mon, Feb 22, 2010 at 3:49 PM, Mark Lord <kernel@teksavvy.com> 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..