On Thu, Jan 23, 2025 at 10:24 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > 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. Hi Matthew, Thanks for the correction. I realized my misassumption after I sent the email, so for v4 [1] I ended up dropping both patch 11 (writeback) and 12 (turning large folios on). [1] https://lore.kernel.org/linux-fsdevel/20250123012448.2479372-1-joannelkoong@xxxxxxxxx/ Thanks, Joanne
