OCFS2-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [Ocfs2-devel] [PATCH] ocfs2: fix potential soft lockup during fstrim
@ 2020-09-27  1:58 Gang He
  2020-09-27  2:59 ` Joseph Qi
  0 siblings, 1 reply; 2+ messages in thread
From: Gang He @ 2020-09-27  1:58 UTC (permalink / raw)
  To: mark, jlbec, joseph.qi; +Cc: Gang He, linux-kernel, ocfs2-devel, akpm

When we discard unused blocks on a mounted ocfs2 filesystem, fstrim
handles each block goup with locking/unlocking global bitmap meta-file
repeatedly. we should let fstrim thread take a break(if need) between
unlock and lock, this will avoid the potential soft lockup problem,
and also gives the upper applications more IO opportunities, these
applications are not blocked for too long at writing files.

Signed-off-by: Gang He <ghe@suse.com>
---
 fs/ocfs2/alloc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
index 4c1b90442d6f..2cf9321919b5 100644
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -7654,8 +7654,10 @@ int ocfs2_trim_mainbm(struct super_block *sb, struct fstrim_range *range)
 	 * main_bm related locks for avoiding the current IO starve, then go to
 	 * trim the next group
 	 */
-	if (ret >= 0 && group <= last_group)
+	if (ret >= 0 && group <= last_group) {
+		cond_resched();
 		goto next_group;
+	}
 out:
 	range->len = trimmed * sb->s_blocksize;
 	return ret;
-- 
2.21.0

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

* [Ocfs2-devel] [PATCH] ocfs2: fix potential soft lockup during fstrim
  2020-09-27  1:58 [Ocfs2-devel] [PATCH] ocfs2: fix potential soft lockup during fstrim Gang He
@ 2020-09-27  2:59 ` Joseph Qi
  0 siblings, 0 replies; 2+ messages in thread
From: Joseph Qi @ 2020-09-27  2:59 UTC (permalink / raw)
  To: Gang He, mark, jlbec; +Cc: linux-kernel, ocfs2-devel, akpm



On 2020/9/27 09:58, Gang He wrote:
> When we discard unused blocks on a mounted ocfs2 filesystem, fstrim
> handles each block goup with locking/unlocking global bitmap meta-file
> repeatedly. we should let fstrim thread take a break(if need) between
> unlock and lock, this will avoid the potential soft lockup problem,
> and also gives the upper applications more IO opportunities, these
> applications are not blocked for too long at writing files.
> 
> Signed-off-by: Gang He <ghe@suse.com>

It makes sense.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>

> ---
>  fs/ocfs2/alloc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c
> index 4c1b90442d6f..2cf9321919b5 100644
> --- a/fs/ocfs2/alloc.c
> +++ b/fs/ocfs2/alloc.c
> @@ -7654,8 +7654,10 @@ int ocfs2_trim_mainbm(struct super_block *sb, struct fstrim_range *range)
>  	 * main_bm related locks for avoiding the current IO starve, then go to
>  	 * trim the next group
>  	 */
> -	if (ret >= 0 && group <= last_group)
> +	if (ret >= 0 && group <= last_group) {
> +		cond_resched();
>  		goto next_group;
> +	}
>  out:
>  	range->len = trimmed * sb->s_blocksize;
>  	return ret;
> 

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

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-27  1:58 [Ocfs2-devel] [PATCH] ocfs2: fix potential soft lockup during fstrim Gang He
2020-09-27  2:59 ` Joseph Qi

OCFS2-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/ocfs2-devel/0 ocfs2-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ocfs2-devel ocfs2-devel/ https://lore.kernel.org/ocfs2-devel \
		ocfs2-devel@oss.oracle.com
	public-inbox-index ocfs2-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.oracle.oss.ocfs2-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git