mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: shaohua.li@intel.com
To: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Cc: jaxboe@fusionio.com, htejun@gmail.com, jgarzik@pobox.com,
	hch@infradead.org, djwong@us.ibm.com,
	Shaohua Li <shaohua.li@intel.com>
Subject: [patch v2 2/3] block: hold queue if flush is running for non-queueable flush drive
Date: Wed, 04 May 2011 16:17:27 +0800	[thread overview]
Message-ID: <20110504082115.270298766@sli10-conroe.sh.intel.com> (raw)
In-Reply-To: <20110504081725.946950281@sli10-conroe.sh.intel.com>

[-- Attachment #1: blk-hold-queue-for-nonqueueable-flush.patch --]
[-- Type: text/plain, Size: 2850 bytes --]

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
workload.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
---
 block/blk-flush.c      |    3 +++
 block/blk.h            |   12 +++++++++++-
 include/linux/blkdev.h |    1 +
 3 files changed, 15 insertions(+), 1 deletion(-)

Index: linux/block/blk-flush.c
===================================================================
--- linux.orig/block/blk-flush.c	2011-05-04 14:20:33.000000000 +0800
+++ linux/block/blk-flush.c	2011-05-04 15:23:50.000000000 +0800
@@ -199,6 +199,9 @@ static void flush_end_io(struct request
 
 	BUG_ON(q->flush_pending_idx == q->flush_running_idx);
 
+	queued |= q->flush_queue_delayed;
+	q->flush_queue_delayed = 0;
+
 	/* account completion of the flush request */
 	q->flush_running_idx ^= 1;
 	elv_completed_request(q, flush_rq);
Index: linux/include/linux/blkdev.h
===================================================================
--- linux.orig/include/linux/blkdev.h	2011-05-04 14:24:40.000000000 +0800
+++ linux/include/linux/blkdev.h	2011-05-04 14:29:29.000000000 +0800
@@ -365,6 +365,7 @@ struct request_queue
 	 */
 	unsigned int		flush_flags;
 	unsigned int		flush_not_queueable:1;
+	unsigned int		flush_queue_delayed:1;
 	unsigned int		flush_pending_idx:1;
 	unsigned int		flush_running_idx:1;
 	unsigned long		flush_pending_since;
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
+		 *  in the drive, we can hold the queue till flush request is
+		 *  finished. Even we don't do this, driver can't dispatch next
+		 *  requests and will requeue them.
+		 */
+		if (q->flush_pending_idx != q->flush_running_idx &&
+				!blk_queue_flush_queueable(q)) {
+			q->flush_queue_delayed = 1;
+			return NULL;
+		}
 		if (!q->elevator->ops->elevator_dispatch_fn(q, 0))
 			return NULL;
 	}


  parent reply	other threads:[~2011-05-04  8:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04  8:17 [patch v2 0/3] block: optimize flush " shaohua.li
2011-05-04  8:17 ` [patch v2 1/3] block: add a non-queueable flush flag shaohua.li
2011-05-04  9:05   ` Tejun Heo
2011-05-04  8:17 ` shaohua.li [this message]
2011-05-04  9:09   ` [patch v2 2/3] block: hold queue if flush is running for non-queueable flush drive Tejun Heo
2011-05-04 10:42   ` Sergei Shtylyov
2011-05-04  8:17 ` [patch v2 3/3] SATA: enable non-queueable flush flag shaohua.li
2011-05-04  8:53   ` Tejun Heo
2011-05-04 10:29     ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110504082115.270298766@sli10-conroe.sh.intel.com \
    --to=shaohua.li@intel.com \
    --cc=djwong@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=htejun@gmail.com \
    --cc=jaxboe@fusionio.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®