Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1466996 > unrolled thread

[PATCH 1/3] f2fs: check return value of write_checkpoint during fstrim

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/3] f2fs: check return value of write_checkpoint during fstrim Chao Yu <chao@kernel.org> - 2016-08-21 17:30 +0200
    [PATCH 2/3] f2fs: schedule in between two continous batch discards Chao Yu <chao@kernel.org> - 2016-08-21 17:30 +0200
      Re: [PATCH 2/3] f2fs: schedule in between two continous batch  discards Jaegeuk Kim <jaegeuk@kernel.org> - 2016-08-23 19:10 +0200

#1466996 — [PATCH 1/3] f2fs: check return value of write_checkpoint during fstrim

From: Chao Yu <yuchao0@huawei.com>

During fstrim, if one of multiple write_checkpoint failed, break off and
return error number to caller.

Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
 fs/f2fs/segment.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index a394012..020767c 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1303,6 +1303,8 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range *range)
 		mutex_lock(&sbi->gc_mutex);
 		err = write_checkpoint(sbi, &cpc);
 		mutex_unlock(&sbi->gc_mutex);
+		if (err)
+			break;
 	}
 out:
 	range->len = F2FS_BLK_TO_BYTES(cpc.trimmed);
-- 
2.7.2

[toc] | [next] | [standalone]

#1466999 — [PATCH 2/3] f2fs: schedule in between two continous batch discards

From: Chao Yu <yuchao0@huawei.com>

In batch discard approach of fstrim will grab/release gc_mutex lock
repeatly, it makes contention of the lock becoming more intensive.

So after one batch discards were issued in checkpoint and the lock
was released, it's better to do schedule() to increase opportunity
of grabbing gc_mutex lock for other competitors.

Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
 fs/f2fs/segment.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 020767c..d0f74eb 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1305,6 +1305,8 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range *range)
 		mutex_unlock(&sbi->gc_mutex);
 		if (err)
 			break;
+
+		schedule();
 	}
 out:
 	range->len = F2FS_BLK_TO_BYTES(cpc.trimmed);
-- 
2.7.2

[toc] | [prev] | [next] | [standalone]

#1468720 — Re: [PATCH 2/3] f2fs: schedule in between two continous batch discards

Hi Chao,

On Sun, Aug 21, 2016 at 11:21:30PM +0800, Chao Yu wrote:
> From: Chao Yu <yuchao0@huawei.com>
> 
> In batch discard approach of fstrim will grab/release gc_mutex lock
> repeatly, it makes contention of the lock becoming more intensive.
> 
> So after one batch discards were issued in checkpoint and the lock
> was released, it's better to do schedule() to increase opportunity
> of grabbing gc_mutex lock for other competitors.
> 
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
> ---
>  fs/f2fs/segment.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 020767c..d0f74eb 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1305,6 +1305,8 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct fstrim_range *range)
>  		mutex_unlock(&sbi->gc_mutex);
>  		if (err)
>  			break;
> +
> +		schedule();

Hmm, if other thread is already waiting for gc_mutex, we don't need this here.
In order to avoid long latency, wouldn't it be enough to reduce the batch size?

Thanks,

>  	}
>  out:
>  	range->len = F2FS_BLK_TO_BYTES(cpc.trimmed);
> -- 
> 2.7.2

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web