On Wed, Jan 22, 2025 at 03:23:08PM -0800, Joanne Koong wrote: > * I'm going to remove the writeback patch (patch 11/12) in this series > and resubmit, and leave large folios writeback to be done as a > separate future patchset. Getting writeback to work with large folios > has a dependency on [1], which unfortunately does not look like it'll > be resolved anytime soon. If we cannot remove tmp pages, then we'll > likely need to use a different data structure than the rb tree to > account for large folios w/ tmp pages. I believe we can still enable > large folios overall even without large folios writeback, as even with > the inode->i_mapping set to a large folio order range, writeback will > still only operate on 4k folios until fgf_set_order() is explicitly > set in fuse_write_begin() for the __filemap_get_folio() call. Maybe you already understand this and just expressed yourself badly, but what you've said isn't true. The fgf_set_order() call is about creating large folios during write(). If instead you do a large read() (or do consecutive read() calls which get turned into large readaheads), you'll get large clean folios. If you then dirty those folios, we won't split them. Writeback will still see large folios in this case. It depends on your workload how common a scenario this is.
