Re: bad performance with SSD since kernel version 2.6.32

[Jens Axboe <jens.axboe@oracle.com>]

On Mon, Feb 22 2010, Robert Hancock wrote:
> 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?

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