Hello. On 04-05-2011 12:17, shaohua.li@xxxxxxxxx wrote:
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. Say we have requests f1, w1, f2 (f is flush request, and w is write request). When f1 is running, queue will be hold, so w1 will not be added to queue list. Just after f1 is finished, f2 will be dispatched. Since f1 already flushs cache out, f2 can be finished very quickly. In my test, the queue holding completely solves a regression introduced by commit 53d63e6b0dfb9588, which is about 20% regression running a sysbench fileio
Please specify that commit's summary -- for human readers. The ID is only immediately usable to gitweb.
workload.
Signed-off-by: Shaohua Li <shaohua.li@xxxxxxxxx>
[...]
Index: linux/block/blk.h =================================================================== --- linux.orig/block/blk.h 2011-05-04 14:20:33.000000000 +0800 +++ linux/block/blk.h 2011-05-04 16:09:42.000000000 +0800 @@ -61,7 +61,17 @@ static inline struct request *__elv_next rq = list_entry_rq(q->queue_head.next); return rq; } - + /* + * Flush request is running and flush request isn't queeueable
Queueable. WBR, Sergei -- 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
