lkml.org 
[lkml]   [2011]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch v2 2/3] block: hold queue if flush is running for non-queueable flush drive
Hello.

On 04-05-2011 12:17, shaohua.li@intel.com 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@intel.com>

[...]

> 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


\
 
 \ /
  Last update: 2011-05-04 12:45    [W:0.061 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site