Re: Splitting dirty fs folios

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 30, 2023 at 08:39:32AM +1000, Dave Chinner wrote:
> > Option 5: If the folio is both dirty and !uptodate, just refuse to split
> > it, like if somebody else had a reference on it.  A less extreme version
> > of #4.
> 
> Also seems like a reasonable first step.
> 
> > I may have missed some other option.  Option 5 seems like the least
> > amount of work.
> 
> *nod*
> 
> Overall, I think the best way to approach it is to do the simplest,
> most obviously correct thing first. If/when we observe performance
> problems from the simple approach, then we can decide how to solve
> that via one of the more complex approaches...

So the good news is that Option 5 seems to have no regressions and
the functional part of the patch looks like ...

+++ b/fs/iomap/buffered-io.c
@@ -510,11 +510,6 @@ void iomap_invalidate_folio(struct folio *folio, size_t off
set, size_t len)
                WARN_ON_ONCE(folio_test_writeback(folio));
                folio_cancel_dirty(folio);
                iomap_page_release(folio);
-       } else if (folio_test_large(folio)) {
-               /* Must release the iop so the page can be split */
-               VM_WARN_ON_ONCE_FOLIO(!folio_test_uptodate(folio) &&
-                               folio_test_dirty(folio), folio);
-               iomap_page_release(folio);
        }
 }
 EXPORT_SYMBOL_GPL(iomap_invalidate_folio);

I need to modify a few comments and document exactly why this works,
but it seems like a good next step.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux