[PATCH] reiserfs: don't use congestion_wait()

[PATCH] reiserfs: don't use congestion_wait()

[NeilBrown]

Block devices do not, in general, report congestion any more, so this
congestion_wait() is effectively just a sleep.

It isn't entirely clear what is being waited for, but as we only wait
when j_async_throttle is elevated, it seems reasonable to stop waiting
when j_async_throttle becomes zero - or after the same timeout.

So change to use wait_event_event_timeout() for waiting, and
wake_up_var() to signal an end to waiting.

Signed-off-by: NeilBrown <neilb@suse.de>
---

I have no idea who might take this.... Jens and Jan have both landed
reiserfs patches recently...

Thanks,
NeilBrown

 fs/reiserfs/journal.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
index 0834b101c316..a3e21160b634 100644
--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -951,7 +951,9 @@ static int reiserfs_async_progress_wait(struct super_block *s)
 		int depth;
 
 		depth = reiserfs_write_unlock_nested(s);
-		congestion_wait(BLK_RW_ASYNC, HZ / 10);
+		wait_var_event_timeout(&j->j_async_throttle,
+				       atomic_read(&j->j_async_throttle) == 0,
+				       HZ / 10);
 		reiserfs_write_lock_nested(s, depth);
 	}
 
@@ -1058,7 +1060,8 @@ static int flush_commit_list(struct super_block *s,
 			put_bh(tbh) ;
 		}
 	}
-	atomic_dec(&journal->j_async_throttle);
+	if (atomic_dec_and_test(&journal->j_async_throttle))
+		wake_up_var(&journal->j_async_throttle);
 
 	for (i = 0; i < (jl->j_len + 1); i++) {
 		bn = SB_ONDISK_JOURNAL_1st_BLOCK(s) +
-- 
2.33.1

Re: [PATCH] reiserfs: don't use congestion_wait()

[Jan Kara]

On Wed 17-11-21 15:34:42, NeilBrown wrote:
> 
> Block devices do not, in general, report congestion any more, so this
> congestion_wait() is effectively just a sleep.
> 
> It isn't entirely clear what is being waited for, but as we only wait
> when j_async_throttle is elevated, it seems reasonable to stop waiting
> when j_async_throttle becomes zero - or after the same timeout.
> 
> So change to use wait_event_event_timeout() for waiting, and
> wake_up_var() to signal an end to waiting.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
> 
> I have no idea who might take this.... Jens and Jan have both landed
> reiserfs patches recently...

Yeah, I guess I can take this one. Honestly the whole code around
j_async_throttle looks a bit suspicious but your patch does not make it
worse so it looks safe to me :).


								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] reiserfs: don't use congestion_wait()

[NeilBrown]

On Thu, 18 Nov 2021, Jan Kara wrote:
> On Wed 17-11-21 15:34:42, NeilBrown wrote:
> > 
> > Block devices do not, in general, report congestion any more, so this
> > congestion_wait() is effectively just a sleep.
> > 
> > It isn't entirely clear what is being waited for, but as we only wait
> > when j_async_throttle is elevated, it seems reasonable to stop waiting
> > when j_async_throttle becomes zero - or after the same timeout.
> > 
> > So change to use wait_event_event_timeout() for waiting, and
> > wake_up_var() to signal an end to waiting.
> > 
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> > 
> > I have no idea who might take this.... Jens and Jan have both landed
> > reiserfs patches recently...
> 
> Yeah, I guess I can take this one. Honestly the whole code around
> j_async_throttle looks a bit suspicious but your patch does not make it
> worse so it looks safe to me :).

Hi,
 I don't see this in linux-next.  Should I ??

Thanks,
NeilBrown

Re: [PATCH] reiserfs: don't use congestion_wait()

[Jan Kara]

On Fri 10-12-21 15:27:44, NeilBrown wrote:
> On Thu, 18 Nov 2021, Jan Kara wrote:
> > On Wed 17-11-21 15:34:42, NeilBrown wrote:
> > > 
> > > Block devices do not, in general, report congestion any more, so this
> > > congestion_wait() is effectively just a sleep.
> > > 
> > > It isn't entirely clear what is being waited for, but as we only wait
> > > when j_async_throttle is elevated, it seems reasonable to stop waiting
> > > when j_async_throttle becomes zero - or after the same timeout.
> > > 
> > > So change to use wait_event_event_timeout() for waiting, and
> > > wake_up_var() to signal an end to waiting.
> > > 
> > > Signed-off-by: NeilBrown <neilb@suse.de>
> > > ---
> > > 
> > > I have no idea who might take this.... Jens and Jan have both landed
> > > reiserfs patches recently...
> > 
> > Yeah, I guess I can take this one. Honestly the whole code around
> > j_async_throttle looks a bit suspicious but your patch does not make it
> > worse so it looks safe to me :).
> 
> Hi,
>  I don't see this in linux-next.  Should I ??

No, my fault. I'm sorry. I didn't push out the resulting branch. Fixed now.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] reiserfs: don't use congestion_wait()

[NeilBrown]

On Tue, 14 Dec 2021, Jan Kara wrote:
> On Fri 10-12-21 15:27:44, NeilBrown wrote:
> > On Thu, 18 Nov 2021, Jan Kara wrote:
> > > On Wed 17-11-21 15:34:42, NeilBrown wrote:
> > > > 
> > > > Block devices do not, in general, report congestion any more, so this
> > > > congestion_wait() is effectively just a sleep.
> > > > 
> > > > It isn't entirely clear what is being waited for, but as we only wait
> > > > when j_async_throttle is elevated, it seems reasonable to stop waiting
> > > > when j_async_throttle becomes zero - or after the same timeout.
> > > > 
> > > > So change to use wait_event_event_timeout() for waiting, and
> > > > wake_up_var() to signal an end to waiting.
> > > > 
> > > > Signed-off-by: NeilBrown <neilb@suse.de>
> > > > ---
> > > > 
> > > > I have no idea who might take this.... Jens and Jan have both landed
> > > > reiserfs patches recently...
> > > 
> > > Yeah, I guess I can take this one. Honestly the whole code around
> > > j_async_throttle looks a bit suspicious but your patch does not make it
> > > worse so it looks safe to me :).
> > 
> > Hi,
> >  I don't see this in linux-next.  Should I ??
> 
> No, my fault. I'm sorry. I didn't push out the resulting branch. Fixed now.
> 

Yes-  I see it in your for-next branch now.  Thanks a lot!

NeilBrown