Sync decompression was introduced to get rid of additional kworker
scheduling overhead. But there is no such overhead in non-atomic
contexts. Therefore, it should be better to turn off sync decompression
to avoid the current thread waiting in z_erofs_runqueue.
Signed-off-by: Huang Jianan
Signed
This patch set was separated form erofs: decompress in endio if possible
since it does these things:
- combine dm-verity and erofs workqueue
- change policy of decompression in context of thread
Huang Jianan (2):
erofs: use workqueue decompression for atomic contexts only
erofs: use sync
z_erofs_decompressqueue_endio may not be executed in the atomic
context, for example, when dm-verity is turned on. In this scenario,
data can be decompressed directly to get rid of additional kworker
scheduling overhead.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
Reviewed-by: Gao
On 2021/3/16 16:26, Chao Yu wrote:
Hi Jianan,
On 2021/3/16 11:15, Huang Jianan via Linux-erofs wrote:
z_erofs_decompressqueue_endio may not be executed in the atomic
context, for example, when dm-verity is turned on. In this scenario,
data can be decompressed directly to get rid of
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed-off-by: Huang Jianan
Signed-off-by: Guo We
.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
Reviewed-by: Gao Xiang
---
fs/erofs/internal.h | 2 ++
fs/erofs/super.c| 1 +
fs/erofs/zdata.c| 15 +--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index
s gc. When
gc_pin_file_threshold is reached, the address of swapfile may change,
but won't be synchronized to swap_extent, so swap will write to wrong
address, which will cause data corruption.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
Reviewed-by: Chao Yu
.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/internal.h | 2 ++
fs/erofs/super.c| 1 +
fs/erofs/zdata.c| 16 +---
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 67a7ec945686..e325da7be237
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed-off-by: Huang Jianan
Signed-off-by: Guo We
.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/internal.h | 3 +++
fs/erofs/super.c| 4
fs/erofs/zdata.c| 16 +---
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 67a7ec945686
On 2021/3/5 16:08, Huang Jianan wrote:
z_erofs_decompressqueue_endio may not be executed in the atomic
context, for example, when dm-verity is turned on. In this scenario,
data can be decompressed directly to get rid of additional kworker
scheduling overhead. Also, it makes no sense to apply
.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/internal.h | 3 +++
fs/erofs/super.c| 4
fs/erofs/zdata.c| 14 +++---
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 67a7ec945686..b817cb85d67b
.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/internal.h | 3 +++
fs/erofs/super.c| 4
fs/erofs/zdata.c| 13 +++--
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 67a7ec945686..b817cb85d67b
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
Signed-off-by: Huang Jianan
Signed-off-by: Guo We
-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/internal.h | 3 ++
fs/erofs/super.c| 1 +
fs/erofs/zdata.c| 102
3 files changed, 60 insertions(+), 46 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index
It should be better to ensure memory allocation during rolling
decompression to avoid io error.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/decompressor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/decompressor.c b/fs/erofs
hich will cause data corruption.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/f2fs/data.c | 109 +++--
1 file changed, 88 insertions(+), 21 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 4dbc1cafc55d..d33085daa3dc 10064
hich will cause data corruption.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/f2fs/data.c | 63 ++
1 file changed, 63 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 4dbc1cafc55d..3e523d6e4643 100644
--- a/fs/f2fs/
Because page_no < sis->max guarantees that the while loop break out
normally, the wrong check contidion here doesn't cause a problem.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/f2fs/data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2
Now swapfile in f2fs directly submit IO to blockdev according to
swapfile extents reported by f2fs when swapon, therefore there is
no need to check IS_SWAPFILE when exec filesystem operation.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/f2fs/data.c | 2 +-
fs/f2fs/f2fs.h | 3
lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
using rolling decompression, a block with a higher compression
ratio will cause a larger memory allocation (up to 64k). It may
cause a large resource burden in extreme cases on devices with
small memory and a large number of concurrent
From: huangjianan
lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
using rolling decompression, a block with a higher compression
ratio will cause a larger memory allocation (up to 64k). It may
cause a large resource burden in extreme cases on devices with
small memory and a large n
Hi Xiang,
On 2021/2/22 12:44, Gao Xiang wrote:
Hi Jianan,
On Thu, Feb 18, 2021 at 08:00:49PM +0800, Huang Jianan via Linux-erofs wrote:
From: huangjianan
lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
using rolling decompression, a block with a higher compression
ratio will
From: huangjianan
lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
using rolling decompression, a block with a higher compression
ratio will cause a larger memory allocation (up to 64k). It may
cause a large resource burden in extreme cases on devices with
small memory and a large n
friendly ping ... 😁
On 2021/2/2 12:11, Huang Jianan via fuse-devel wrote:
Hi all,
This patch works well in our product, but I am not sure this is the
correct
way to solve this problem. I think that the inode->i_count shouldn't be
zero after iput is executed in dentry_unlink_ino
re iget is missing.
Thanks,
Jianan
On 2021/2/2 12:08, Huang Jianan wrote:
We found the following deadlock situations in low memory scenarios:
Thread A Thread B
- __writeback_single_inode
- fuse_write_inode
- fuse_simple_request
- __fuse_request_send
- r
allocating memory in fuse_copy_fill, so there will be no memory
reclaimation in super_cache_scan.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/fuse/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 588f8d1240aa..e580b9d04c25
Hi Christoph,
The reason we use dio is because we need to deploy the patch on some
early kernel versions, and we don't pay much attention to the change of
iomap. Anyway, I will study the problem mentioned by Gao Xiang and try
to convert the current patch to iomap.
Thanks,
Jianan
On Wed, D
From: huangjianan
add direct IO test for the stress tool which was mentioned here:
https://lore.kernel.org/linux-erofs/20200206135631.1491-1-hsiang...@aol.com/
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
stress.c | 20 +---
1 file changed, 17 insertions(+), 3
-erofs/20200206135631.1491-1-hsiang...@aol.com/
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/data.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index ea4f693bee22..3067aa3defff 100644
Thanks for reminding me, I will pay attention about this next time.
在 2020/12/10 10:36, Gao Xiang 写道:
Hi Jianan,
On Wed, Dec 09, 2020 at 07:57:40PM +0800, Huang Jianan wrote:
iblock indicates the number of i_blkbits-sized blocks rather than
sectors.
In addition, considering buffer_head
iblock indicates the number of i_blkbits-sized blocks rather than
sectors.
In addition, considering buffer_head limits mapped size to 32-bits,
should avoid using generic_block_bmap.
Fixes: 9da681e017a3 ("staging: erofs: support bmap")
Signed-off-by: Huang Jianan
Signed-off-by: G
Thanks for review, i will update it soon.
在 2020/12/9 19:39, Gao Xiang 写道:
Hi Jianan,
On Wed, Dec 09, 2020 at 06:08:41PM +0800, Chao Yu wrote:
On 2020/12/9 10:39, Huang Jianan wrote:
iblock indicates the number of i_blkbits-sized blocks rather than
sectors.
In addition, considering
iblock indicates the number of i_blkbits-sized blocks rather than
sectors.
In addition, considering buffer_head limits mapped size to 32-bits,
should avoid using generic_block_bmap.
Fixes: 9da681e017a3 ("staging: erofs: support bmap")
Signed-off-by: Huang Jianan
Signed-off-by: G
在 2020/12/8 21:11, Huang Jianan 写道:
iblock indicates the number of i_blkbits-sized blocks rather than
sectors.
In addition, considering buffer_head limits mapped size to 32-bits,
should avoid using generic_block_bmap.
Fixes: 9da681e017a3 ("staging: erofs: support bmap")
Signed-off
iblock indicates the number of i_blkbits-sized blocks rather than
sectors.
In addition, considering buffer_head limits mapped size to 32-bits,
should avoid using generic_block_bmap.
Fixes: 9da681e017a3 ("staging: erofs: support bmap")
Signed-off-by: Huang Jianan
Signed-off-by: G
36 matches
Mail list logo
