[PATCH] md: drop queue limitation for RAID1 and RAID10

As suggested by Neil Brown[1], this limitation seems to be
deprecated.

With plugging in use, writes are processed behind the raid thread
and conf->pending_count is not increased. This limitation occurs only
if caller doesn't use plugs.

It can be avoided and often it is (with plugging). There are no reports
that queue is growing to enormous size so remove queue limitation for
non-plugged IOs too.

[1] https://lore.kernel.org/linux-raid/162496301481.7211.18031090130574610495@noble.neil.brown.name

Signed-off-by: Mariusz Tkaczyk <redacted>
---
 drivers/md/raid1-10.c | 6 ------
 drivers/md/raid1.c    | 7 -------
 drivers/md/raid10.c   | 7 -------
 3 files changed, 20 deletions(-)

diff --git a/drivers/md/raid1-10.c b/drivers/md/raid1-10.c
index 54db34163968..83f9a4f3d82e 100644
--- a/drivers/md/raid1-10.c
+++ b/drivers/md/raid1-10.c

@@ -22,12 +22,6 @@
 
 #define BIO_SPECIAL(bio) ((unsigned long)bio <= 2)
 
-/* When there are this many requests queue to be written by
- * the raid thread, we become 'congested' to provide back-pressure
- * for writeback.
- */
-static int max_queued_requests = 1024;
-
 /* for managing resync I/O pages */
 struct resync_pages {
 	void		*raid_bio;

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 7dc8026cf6ee..eeaedd6e0ce1 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c

@@ -1358,12 +1358,6 @@ static void raid1_write_request(struct mddev *mddev, struct bio *bio,
 	r1_bio = alloc_r1bio(mddev, bio);
 	r1_bio->sectors = max_write_sectors;
 
-	if (conf->pending_count >= max_queued_requests) {
-		md_wakeup_thread(mddev->thread);
-		raid1_log(mddev, "wait queued");
-		wait_event(conf->wait_barrier,
-			   conf->pending_count < max_queued_requests);
-	}
 	/* first select target devices under rcu_lock and
 	 * inc refcount on their rdev.  Record them by setting
 	 * bios[x] to bio

@@ -3410,4 +3404,3 @@ MODULE_ALIAS("md-personality-3"); /* RAID1 */
 MODULE_ALIAS("md-raid1");
 MODULE_ALIAS("md-level-1");
 
-module_param(max_queued_requests, int, S_IRUGO|S_IWUSR);

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index dde98f65bd04..c683ba138b58 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c

@@ -1387,12 +1387,6 @@ static void raid10_write_request(struct mddev *mddev, struct bio *bio,
 		conf->reshape_safe = mddev->reshape_position;
 	}
 
-	if (conf->pending_count >= max_queued_requests) {
-		md_wakeup_thread(mddev->thread);
-		raid10_log(mddev, "wait queued");
-		wait_event(conf->wait_barrier,
-			   conf->pending_count < max_queued_requests);
-	}
 	/* first select target devices under rcu_lock and
 	 * inc refcount on their rdev.  Record them by setting
 	 * bios[x] to bio

@@ -5243,4 +5237,3 @@ MODULE_ALIAS("md-personality-9"); /* RAID10 */
 MODULE_ALIAS("md-raid10");
 MODULE_ALIAS("md-level-10");
 
-module_param(max_queued_requests, int, S_IRUGO|S_IWUSR);

-- 
2.26.2

On Fri, Dec 17, 2021 at 1:30 AM Mariusz Tkaczyk
[off-list ref] wrote:

As suggested by Neil Brown[1], this limitation seems to be
deprecated.

With plugging in use, writes are processed behind the raid thread
and conf->pending_count is not increased. This limitation occurs only
if caller doesn't use plugs.

It can be avoided and often it is (with plugging). There are no reports
that queue is growing to enormous size so remove queue limitation for
non-plugged IOs too.

[1] https://lore.kernel.org/linux-raid/162496301481.7211.18031090130574610495@noble.neil.brown.name

Signed-off-by: Mariusz Tkaczyk <redacted>

I applied this patch to md-next, cecause it helps simplify Vishal's patches
for REQ_NOWAIT. However, I think this change is not complete, as we can
now remove pending_count from r1conf and r10conf. Please send patch
on top of md-next to clean up pending_count.

Thanks,
Song

On Sat, 1 Jan 2022 16:30:07 -0800
Song Liu [off-list ref] wrote:

On Fri, Dec 17, 2021 at 1:30 AM Mariusz Tkaczyk
[off-list ref] wrote:

quoted

As suggested by Neil Brown[1], this limitation seems to be
deprecated.

With plugging in use, writes are processed behind the raid thread
and conf->pending_count is not increased. This limitation occurs
only if caller doesn't use plugs.

It can be avoided and often it is (with plugging). There are no
reports that queue is growing to enormous size so remove queue
limitation for non-plugged IOs too.

[1]
https://lore.kernel.org/linux-raid/162496301481.7211.18031090130574610495@noble.neil.brown.name

Signed-off-by: Mariusz Tkaczyk <redacted>  

I applied this patch to md-next, cecause it helps simplify Vishal's
patches for REQ_NOWAIT. However, I think this change is not complete,
as we can now remove pending_count from r1conf and r10conf. Please
send patch on top of md-next to clean up pending_count.

Should I also remove pending_cnt from raid1_plug_cb and raid10_plug_cb?

Thanks,
Mariusz

On Mon, Jan 3, 2022 at 7:33 AM Mariusz Tkaczyk
[off-list ref] wrote:

On Sat, 1 Jan 2022 16:30:07 -0800
Song Liu [off-list ref] wrote:

quoted

On Fri, Dec 17, 2021 at 1:30 AM Mariusz Tkaczyk
[off-list ref] wrote:

quoted

As suggested by Neil Brown[1], this limitation seems to be
deprecated.

With plugging in use, writes are processed behind the raid thread
and conf->pending_count is not increased. This limitation occurs
only if caller doesn't use plugs.

It can be avoided and often it is (with plugging). There are no
reports that queue is growing to enormous size so remove queue
limitation for non-plugged IOs too.

[1]
https://lore.kernel.org/linux-raid/162496301481.7211.18031090130574610495@noble.neil.brown.name

Signed-off-by: Mariusz Tkaczyk <redacted>

I applied this patch to md-next, cecause it helps simplify Vishal's
patches for REQ_NOWAIT. However, I think this change is not complete,
as we can now remove pending_count from r1conf and r10conf. Please
send patch on top of md-next to clean up pending_count.

Should I also remove pending_cnt from raid1_plug_cb and raid10_plug_cb?

Yeah, I think we should also remove pending_cnt.

Thanks,
Song