fs/f2fs/data.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
From: Jiucheng Xu <jiucheng.xu@amlogic.com>
On 32-bit architectures, when GFP_NOFS is used, the file cache for write
operations cannot be allocated from the highmem and CMA.
Since mapping->gfp_mask is set to GFP_HIGHUSER_MOVABLE during inode
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 <jiucheng.xu@amlogic.com>
---
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,
--
Jiucheng Xu <jiucheng.xu@amlogic.com>
On 9/18/25 11:32, Jiucheng Xu via B4 Relay wrote: > From: Jiucheng Xu <jiucheng.xu@amlogic.com> > > 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? > > 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. 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 <jiucheng.xu@amlogic.com> > --- > 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,
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 <jiucheng.xu@amlogic.com> >> >> 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 <jiucheng.xu@amlogic.com> >> --- >> 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, >
© 2016 - 2025 Red Hat, Inc.