Thank you very much for your prompt and insightful reply! I truly appreciate you taking the time to address my question so quickly.
I understand now. It seems the kernel's flusher threads are indeed sufficient for handling dirty page writeback effectively. And I realize that they ultimately call `do_writepages` to execute the file system's specific `writepages` implementation. It's also clear that the scenario where `kswapd` initiates dirty page writeback is relatively infrequent. Knowing that the F2FS community is currently heavily invested in the folio support effort, I wanted to also bring up some observations and questions regarding folio support in F2FS garbage collection. Specifically, I'm concerned about the challenge of allocating high-order folios due to non-contiguous index ranges during the GC process. I've initiated a discussion about this issue on the f2fs mailing list in an email thread.[https://lore.kernel.org/linux-f2fs-devel/CAMLCH1F8niz3qifu9pt6C3yLhonadD=feaptwkhcard8fpj...@mail.gmail.com/T/#u] I would be grateful if you and other developers could take a look and share your thoughts. Best regards, Matthew Wilcox <wi...@infradead.org> 于2025年3月23日周日 22:28写道： > > On Sun, Mar 23, 2025 at 07:34:59PM +0800, Nanzhe Zhao wrote: > > I've recently been studying your patch 'f2fs: Remove uses of > > writepage'. I understand the rationale behind it, especially with the > > page cache and file I/O increasingly adopting folios in place of the > > traditional page structure. This trend indeed renders the legacy > > `writepage` function in file systems not only unnecessary but > > potentially detrimental. This is particularly true for file systems > > like F2FS, which, as you know, has already fully implemented the > > `writepages` function for all its `address_space_operations`. > > > > However, as you've pointed out, the `pageout` function within vmscan, > > which `kswapd` uses for dirty page writeback, doesn't currently > > support calling the file system's > > `address_space_operations->writepages`. I was wondering if you have > > any plans to improve this situation, and if so, could you perhaps > > share some insights into the general direction or approach you might > > be considering? > > commit 21b4ee7029c9 > Author: Dave Chinner <dchin...@redhat.com> > Date: Tue Aug 10 18:33:41 2021 -0700 > > xfs: drop ->writepage completely > > ->writepage is only used in one place - single page writeback from > memory reclaim. We only allow such writeback from kswapd, not from > direct memory reclaim, and so it is rarely used. When it comes from > kswapd, it is effectively random dirty page shoot-down, which is > horrible for IO patterns. We will already have background writeback > trying to clean all the dirty pages in memory as efficiently as > possible, so having kswapd interrupt our well formed IO stream only > slows things down. So get rid of xfs_vm_writepage() completely. > > Signed-off-by: Dave Chinner <dchin...@redhat.com> > [djwong: forward port to 5.15] > Reviewed-by: Darrick J. Wong <djw...@kernel.org> > Signed-off-by: Darrick J. Wong <djw...@kernel.org> > > > https://lore.kernel.org/linux-fsdevel/20181109151239.gd9...@infradead.org/ > > There's probably some other good documentation around why we're doing > this, but this is all I have handy. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
