| Message ID | 167172134962.2334525.570622889806603086.stgit@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm, netfs, fscache: Stop read optimisation when folio removed from pagecache | expand |
On Thu, Dec 22, 2022 at 03:02:29PM +0000, David Howells wrote: > Make filemap_release_folio() return one of three values: > > (0) FILEMAP_CANT_RELEASE_FOLIO > > Couldn't release the folio's private data, so the folio can't itself > be released. > > (1) FILEMAP_RELEASED_FOLIO > > The private data on the folio was released and the folio can be > released. > > (2) FILEMAP_FOLIO_HAD_NO_PRIVATE These names read really odd, due to the different placementments of FOLIO, the present vs past tense and the fact that 2 also released the folio, and the reliance of callers that one value of an enum must be 0, while no unprecedented, is a bit ugly. But do we even need them? What abut just open coding filemap_release_folio (which is a mostly trivial function) in shrink_folio_list, which is the only place that cares? if (folio_has_private(folio) && folio_needs_release(folio)) { if (folio_test_writeback(folio)) goto activate_locked; if (mapping && mapping->a_ops->release_folio) { if (!mapping->a_ops->release_folio(folio, gfp)) goto activate_locked; } else { if (!try_to_free_buffers(folio)) goto activate_locked; } if (!mapping && folio_ref_count(folio) == 1) { ... alternatively just keep using filemap_release_folio and just add the folio_needs_release in the first branch. That duplicates the test, but makes the change a one-liner.
On Fri, Dec 23, 2022 at 07:31:14AM -0800, Christoph Hellwig wrote: > On Thu, Dec 22, 2022 at 03:02:29PM +0000, David Howells wrote: > > Make filemap_release_folio() return one of three values: > > > > (0) FILEMAP_CANT_RELEASE_FOLIO > > > > Couldn't release the folio's private data, so the folio can't itself > > be released. > > > > (1) FILEMAP_RELEASED_FOLIO > > > > The private data on the folio was released and the folio can be > > released. > > > > (2) FILEMAP_FOLIO_HAD_NO_PRIVATE > > These names read really odd, due to the different placementments > of FOLIO, the present vs past tense and the fact that 2 also released > the folio, and the reliance of callers that one value of an enum > must be 0, while no unprecedented, is a bit ugly. Agreed. The thing is that it's not the filemap that's being released, it's the folio. So these should be: FOLIO_RELEASE_SUCCESS FOLIO_RELEASE_FAILED FOLIO_RELEASE_NO_PRIVATE ... but of course, NO_PRIVATE is also a success. So it's a really weird thing to be reporting. I'm with you on the latter half of this email: > But do we even need them? What abut just open coding > filemap_release_folio (which is a mostly trivial function) in > shrink_folio_list, which is the only place that cares? > > if (folio_has_private(folio) && folio_needs_release(folio)) { > if (folio_test_writeback(folio)) > goto activate_locked; > > if (mapping && mapping->a_ops->release_folio) { > if (!mapping->a_ops->release_folio(folio, gfp)) > goto activate_locked; > } else { > if (!try_to_free_buffers(folio)) > goto activate_locked; > } > > if (!mapping && folio_ref_count(folio) == 1) { > ... > > alternatively just keep using filemap_release_folio and just add the > folio_needs_release in the first branch. That duplicates the test, > but makes the change a one-liner. Or just drop patch 3 entirely?
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index a0d433e0addd..cd00fb3b524b 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -1121,7 +1121,12 @@ void __filemap_remove_folio(struct folio *folio, void *shadow); void replace_page_cache_folio(struct folio *old, struct folio *new); void delete_from_page_cache_batch(struct address_space *mapping, struct folio_batch *fbatch); -bool filemap_release_folio(struct folio *folio, gfp_t gfp); +enum filemap_released_folio { + FILEMAP_CANT_RELEASE_FOLIO = 0, /* (This must be 0) Release failed */ + FILEMAP_RELEASED_FOLIO = 1, /* Folio's private data released */ + FILEMAP_FOLIO_HAD_NO_PRIVATE = 2, /* Folio had no private data */ +}; +enum filemap_released_folio filemap_release_folio(struct folio *folio, gfp_t gfp); loff_t mapping_seek_hole_data(struct address_space *, loff_t start, loff_t end, int whence); diff --git a/mm/filemap.c b/mm/filemap.c index 344146c170b0..217ca847773a 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3953,20 +3953,28 @@ EXPORT_SYMBOL(generic_file_write_iter); * this page (__GFP_IO), and whether the call may block * (__GFP_RECLAIM & __GFP_FS). * - * Return: %true if the release was successful, otherwise %false. + * Return: %FILEMAP_RELEASED_FOLIO if the release was successful, + * %FILEMAP_CANT_RELEASE_FOLIO if the private data couldn't be released and + * %FILEMAP_FOLIO_HAD_NO_PRIVATE if there was no private data. */ -bool filemap_release_folio(struct folio *folio, gfp_t gfp) +enum filemap_released_folio filemap_release_folio(struct folio *folio, + gfp_t gfp) { struct address_space * const mapping = folio->mapping; + bool released; BUG_ON(!folio_test_locked(folio)); if (!folio_needs_release(folio)) - return true; + return FILEMAP_FOLIO_HAD_NO_PRIVATE; if (folio_test_writeback(folio)) - return false; + return FILEMAP_CANT_RELEASE_FOLIO; if (mapping && mapping->a_ops->release_folio) - return mapping->a_ops->release_folio(folio, gfp); - return try_to_free_buffers(folio); + released = mapping->a_ops->release_folio(folio, gfp); + else + released = try_to_free_buffers(folio); + + return released ? + FILEMAP_RELEASED_FOLIO : FILEMAP_CANT_RELEASE_FOLIO; } EXPORT_SYMBOL(filemap_release_folio); diff --git a/mm/vmscan.c b/mm/vmscan.c index bded71961143..b1e5ca348223 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1996,25 +1996,26 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, * (refcount == 1) it can be freed. Otherwise, leave * the folio on the LRU so it is swappable. */ - if (folio_needs_release(folio)) { - if (!filemap_release_folio(folio, sc->gfp_mask)) - goto activate_locked; + switch (filemap_release_folio(folio, sc->gfp_mask)) { + case FILEMAP_CANT_RELEASE_FOLIO: + goto activate_locked; + case FILEMAP_RELEASED_FOLIO: if (!mapping && folio_ref_count(folio) == 1) { folio_unlock(folio); if (folio_put_testzero(folio)) goto free_it; - else { - /* - * rare race with speculative reference. - * the speculative reference will free - * this folio shortly, so we may - * increment nr_reclaimed here (and - * leave it off the LRU). - */ - nr_reclaimed += nr_pages; - continue; - } + /* + * rare race with speculative reference. the + * speculative reference will free this folio + * shortly, so we may increment nr_reclaimed + * here (and leave it off the LRU). + */ + nr_reclaimed += nr_pages; + continue; } + break; + case FILEMAP_FOLIO_HAD_NO_PRIVATE: + break; } if (folio_test_anon(folio) && !folio_test_swapbacked(folio)) {
Make filemap_release_folio() return one of three values: (0) FILEMAP_CANT_RELEASE_FOLIO Couldn't release the folio's private data, so the folio can't itself be released. (1) FILEMAP_RELEASED_FOLIO The private data on the folio was released and the folio can be released. (2) FILEMAP_FOLIO_HAD_NO_PRIVATE There was no private data on the folio and the folio can be released. The first must be zero so that existing tests of !filemap_release_folio() continue to work as expected; similarly the other two must both be non-zero so that existing tests of filemap_release_folio() continue to work as expected. Using this, make shrink_folio_list() choose which of three cases to follow based on the return from filemap_release_folio() rather than testing the folio's private bit itself. Signed-off-by: David Howells <dhowells@redhat.com> cc: Matthew Wilcox <willy@infradead.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: Steve French <sfrench@samba.org> cc: Shyam Prasad N <nspmangalore@gmail.com> cc: Rohith Surabattula <rohiths.msft@gmail.com> cc: Dave Wysochanski <dwysocha@redhat.com> cc: Dominique Martinet <asmadeus@codewreck.org> cc: Ilya Dryomov <idryomov@gmail.com> cc: linux-cachefs@redhat.com cc: linux-cifs@vger.kernel.org cc: linux-afs@lists.infradead.org cc: v9fs-developer@lists.sourceforge.net cc: ceph-devel@vger.kernel.org cc: linux-nfs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/1459152.1669208550@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/166924373637.1772793.2622483388224911574.stgit@warthog.procyon.org.uk/ # v4 --- include/linux/pagemap.h | 7 ++++++- mm/filemap.c | 20 ++++++++++++++------ mm/vmscan.c | 29 +++++++++++++++-------------- 3 files changed, 35 insertions(+), 21 deletions(-)