[v5,3/3] mm: Make filemap_release_folio() better inform shrink_folio_list()
Commit Message
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(-)
Comments
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?
@@ -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);
@@ -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);
@@ -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)) {