On 9/24/2025 10:25 AM, Chao Yu wrote:
[ EXTERNAL EMAIL ]
On 9/18/25 11:32, Jiucheng Xu via B4 Relay wrote:
From: Jiucheng Xu <[email protected]>
On 32-bit architectures, when GFP_NOFS is used, the file cache for write
operations cannot be allocated from the highmem and CMA.
Hi,
Have you suffered any problem w/o this patch? Can you please describe more
details about it?
Hi Chao,
Thanks for your comments.
Our a platform uses a 1.5G DRAM, and the kernel is aarch32.
We have a critical scenario where system need to record multimedia data
while replaying the previously recorded multimedia files. However,
stuttering often occurs during playback. The problem does not arise on
aarch64 platforms with the same memory size.
We have analyzed the root cause as follows:
Data written using GFP_NOFS is only allocated from normal memory. Since
the normal memory is only 768MB, it easily triggers the kswapd to
reclaim memory, which in turn reclaims and clears the file cache of the
recorded data. As a result, during playback, the system fails to hit the
file cache and thus has to re-read data directly from the storage. Given
that our storage has relatively poor performance, concurrent read
(playback) and write (recording) operations lead to significant IO
latency. High read latency then causes stuttering during playback.
Since mapping->gfp_mask is set to GFP_HIGHUSER_MOVABLE during inode
GFP_HIGHUSER_MOVABLE includes __GFP_FS, we should avoid using __GFP_FS here.
f2fs_write_begin() uses GFP_NOFS like the most of other filesystem to avoid
potential deadlock, as __filemap_get_folio(, .. |__GFP_FS | ..) may run into
memory reclaim to call ->writeback in where we may suffer deadlock potentially.
Since our platform only support 5.15 kernel, I have checked
EXT4/FAT/ntfs3 and find they all use mapping_gfp_mask(mapping)) as GFP
flag to get page cache on kernel 5.15:
6100cca:
___GFP_HIGHMEM |___GFP_MOVABLE | ___GFP_IO | ___GFP_FS
|___GFP_DIRECT_RECLAIM |___GFP_KSWAPD_RECLAIM |___GFP_HARDWALL
|___GFP_SKIP_KASAN_UNPOISON | ___GFP_SKIP_KASAN_POISON
therefor that's why I recommend this flag.
I'm not sure if the above flags has some problems on f2fs, so I submit
it and would be very eager to learn about the views of your experts.
Thanks and Best Regards,
Jiucheng
Thanks,
allocation, using mapping_gfp_mask(mapping) as the GFP flag of getting file
cache for writing is more efficient for 32-bit architectures.
Signed-off-by: Jiucheng Xu <[email protected]>
---
fs/f2fs/data.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index
7961e0ddfca3aaa332b7dbd4985ae7766551834f..9fbc41f9accb2626da22754f1a424da4805ca823
100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3587,7 +3587,8 @@ static int f2fs_write_begin(const struct kiocb *iocb,
* Will wait that below with our IO control.
*/
folio = __filemap_get_folio(mapping, index,
- FGP_LOCK | FGP_WRITE | FGP_CREAT, GFP_NOFS);
+ FGP_LOCK | FGP_WRITE | FGP_CREAT,
+ mapping_gfp_mask(mapping));
if (IS_ERR(folio)) {
err = PTR_ERR(folio);
goto fail;
---
base-commit: c872b6279cd26762339ff02513e2a3f16149a6f1
change-id: 20250910-origin-dev-8a5ff6bee1f2
Best regards,
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
