All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] md: drop queue limitation for RAID1 and RAID10
@ 2021-12-17  9:29 Mariusz Tkaczyk
  2022-01-02  0:30 ` Song Liu
  0 siblings, 1 reply; 4+ messages in thread
From: Mariusz Tkaczyk @ 2021-12-17  9:29 UTC (permalink / raw)
  To: song; +Cc: linux-raid

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 <mariusz.tkaczyk@linux.intel.com>
---
 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


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

* Re: [PATCH] md: drop queue limitation for RAID1 and RAID10
  2021-12-17  9:29 [PATCH] md: drop queue limitation for RAID1 and RAID10 Mariusz Tkaczyk
@ 2022-01-02  0:30 ` Song Liu
  2022-01-03 15:33   ` Mariusz Tkaczyk
  0 siblings, 1 reply; 4+ messages in thread
From: Song Liu @ 2022-01-02  0:30 UTC (permalink / raw)
  To: Mariusz Tkaczyk; +Cc: linux-raid

On Fri, Dec 17, 2021 at 1:30 AM Mariusz Tkaczyk
<mariusz.tkaczyk@linux.intel.com> 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 <mariusz.tkaczyk@linux.intel.com>

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

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

* Re: [PATCH] md: drop queue limitation for RAID1 and RAID10
  2022-01-02  0:30 ` Song Liu
@ 2022-01-03 15:33   ` Mariusz Tkaczyk
  2022-01-04 16:42     ` Song Liu
  0 siblings, 1 reply; 4+ messages in thread
From: Mariusz Tkaczyk @ 2022-01-03 15:33 UTC (permalink / raw)
  To: Song Liu; +Cc: linux-raid

On Sat, 1 Jan 2022 16:30:07 -0800
Song Liu <song@kernel.org> wrote:

> On Fri, Dec 17, 2021 at 1:30 AM Mariusz Tkaczyk
> <mariusz.tkaczyk@linux.intel.com> 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 <mariusz.tkaczyk@linux.intel.com>  
> 
> 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


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

* Re: [PATCH] md: drop queue limitation for RAID1 and RAID10
  2022-01-03 15:33   ` Mariusz Tkaczyk
@ 2022-01-04 16:42     ` Song Liu
  0 siblings, 0 replies; 4+ messages in thread
From: Song Liu @ 2022-01-04 16:42 UTC (permalink / raw)
  To: Mariusz Tkaczyk; +Cc: linux-raid

On Mon, Jan 3, 2022 at 7:33 AM Mariusz Tkaczyk
<mariusz.tkaczyk@linux.intel.com> wrote:
>
> On Sat, 1 Jan 2022 16:30:07 -0800
> Song Liu <song@kernel.org> wrote:
>
> > On Fri, Dec 17, 2021 at 1:30 AM Mariusz Tkaczyk
> > <mariusz.tkaczyk@linux.intel.com> 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 <mariusz.tkaczyk@linux.intel.com>
> >
> > 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

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

end of thread, other threads:[~2022-01-04 16:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-17  9:29 [PATCH] md: drop queue limitation for RAID1 and RAID10 Mariusz Tkaczyk
2022-01-02  0:30 ` Song Liu
2022-01-03 15:33   ` Mariusz Tkaczyk
2022-01-04 16:42     ` Song Liu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.