linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] raid1/raid10: slow down resync if there is non-resync activity pending
@ 2016-06-13 13:51 Tomasz Majchrzak
  2016-06-13 18:48 ` Shaohua Li
  0 siblings, 1 reply; 2+ messages in thread
From: Tomasz Majchrzak @ 2016-06-13 13:51 UTC (permalink / raw)
  To: linux-raid

A performance drop of mkfs has been observed on RAID10 during resync
since commit 09314799e4f0 ("md: remove 'go_faster' option from
->sync_request()"). Resync sends so many IOs it slows down non-resync
IOs significantly (few times). Add a short delay to a resync. The
previous long sleep (1s) has proven unnecessary, even very short delay
brings performance right.

The change also applied to raid1. The problem has not been observed on
raid1, however it shares barriers code with raid10 so it might be an
issue for some setup too.

Suggested-by: NeilBrown <neilb@suse.com>
Link: http://lkml.kernel.org/r/20160609134555.GA9104@proton.igk.intel.com
Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
 drivers/md/raid1.c  | 7 +++++++
 drivers/md/raid10.c | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 39fb21e..03c5349 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2535,6 +2535,13 @@ static sector_t raid1_sync_request(struct mddev *mddev, sector_t sector_nr,
 		return sync_blocks;
 	}
 
+	/*   
+	* If there is non-resync activity waiting for a turn,
+	* then let it though before starting on this new sync request.
+	*/
+	if (conf->nr_waiting)
+		schedule_timeout_uninterruptible(1);
+
 	/* we are incrementing sector_nr below. To be safe, we check against
 	 * sector_nr + two times RESYNC_SECTORS
 	 */
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..8a4791e 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2912,6 +2912,13 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr,
 	    max_sector > (sector_nr | chunk_mask))
 		max_sector = (sector_nr | chunk_mask) + 1;
 
+	/*
+	* If there is non-resync activity waiting for a turn,
+	* then let it though before starting on this new sync request.
+	*/
+	if (conf->nr_waiting)
+		schedule_timeout_uninterruptible(1);
+
 	/* Again, very different code for resync and recovery.
 	 * Both must result in an r10bio with a list of bios that
 	 * have bi_end_io, bi_sector, bi_bdev set,
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] raid1/raid10: slow down resync if there is non-resync activity pending
  2016-06-13 13:51 [PATCH] raid1/raid10: slow down resync if there is non-resync activity pending Tomasz Majchrzak
@ 2016-06-13 18:48 ` Shaohua Li
  0 siblings, 0 replies; 2+ messages in thread
From: Shaohua Li @ 2016-06-13 18:48 UTC (permalink / raw)
  To: Tomasz Majchrzak; +Cc: linux-raid

On Mon, Jun 13, 2016 at 03:51:19PM +0200, Tomasz Majchrzak wrote:
> A performance drop of mkfs has been observed on RAID10 during resync
> since commit 09314799e4f0 ("md: remove 'go_faster' option from
> ->sync_request()"). Resync sends so many IOs it slows down non-resync
> IOs significantly (few times). Add a short delay to a resync. The
> previous long sleep (1s) has proven unnecessary, even very short delay
> brings performance right.
> 
> The change also applied to raid1. The problem has not been observed on
> raid1, however it shares barriers code with raid10 so it might be an
> issue for some setup too.

Applied, thanks!

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-06-13 18:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-13 13:51 [PATCH] raid1/raid10: slow down resync if there is non-resync activity pending Tomasz Majchrzak
2016-06-13 18:48 ` Shaohua Li

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).