]> git.baikalelectronics.ru Git - kernel.git/commit
block: hold queue if flush is running for non-queueable flush drive
authorshaohua.li@intel.com <shaohua.li@intel.com>
Fri, 6 May 2011 17:34:41 +0000 (11:34 -0600)
committerJens Axboe <jaxboe@fusionio.com>
Fri, 6 May 2011 17:36:25 +0000 (11:36 -0600)
commit7c2e6e82180c9d513187be47c239767f4ada4a5d
tree933d5ab6ff9b0763f36e614962abb5bdcc4a348a
parent2ac10d3340c2f851a161a87620e092af9293e4f6
block: hold queue if flush is running for non-queueable flush drive

In some drives, flush requests are non-queueable. When flush request is
running, normal read/write requests can't run. If block layer dispatches
such request, driver can't handle it and requeue it.  Tejun suggested we
can hold the queue when flush is running. This can avoid unnecessary
requeue.  Also this can improve performance. For example, we have
request flush1, write1, flush 2. flush1 is dispatched, then queue is
hold, write1 isn't inserted to queue. After flush1 is finished, flush2
will be dispatched. Since disk cache is already clean, flush2 will be
finished very soon, so looks like flush2 is folded to flush1.

In my test, the queue holding completely solves a regression introduced by
commit 6184a27624da949a5ae12384b19e495f50839aef:

    block: make the flush insertion use the tail of the dispatch list

    It's not a preempt type request, in fact we have to insert it
    behind requests that do specify INSERT_FRONT.

which causes about 20% regression running a sysbench fileio
workload.

Stable: 2.6.39 only

Cc: stable@kernel.org
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
block/blk-flush.c
block/blk.h
include/linux/blkdev.h