[PATCH v2 1/9] 9p: Add a migrate_folio method

[PATCH v2 1/9] 9p: Add a migrate_folio method

[Matthew Wilcox (Oracle)]

The migration code used to be able to migrate dirty 9p folios by writing
them back using writepage.  When the writepage method was removed,
we neglected to add a migrate_folio method, which means that dirty 9p
folios have been unmovable ever since.  This reduced our success at
defragmenting memory on machines which use 9p heavily.

Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter)
Cc: stable@vger.kernel.org
Cc: David Howells <dhowells@redhat.com>
Cc: v9fs@lists.linux.dev
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 fs/9p/vfs_addr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
index 32619d146cbc..1286d96a29bc 100644
--- a/fs/9p/vfs_addr.c
+++ b/fs/9p/vfs_addr.c
@@ -164,4 +164,5 @@ const struct address_space_operations v9fs_addr_operations = {
 	.invalidate_folio	= netfs_invalidate_folio,
 	.direct_IO		= noop_direct_IO,
 	.writepages		= netfs_writepages,
+	.migrate_folio		= filemap_migrate_folio,
 };
-- 
2.47.2

Re: [PATCH v2 1/9] 9p: Add a migrate_folio method

[David Howells]

Matthew Wilcox (Oracle) <willy@infradead.org> wrote:

> The migration code used to be able to migrate dirty 9p folios by writing
> them back using writepage.  When the writepage method was removed,
> we neglected to add a migrate_folio method, which means that dirty 9p
> folios have been unmovable ever since.  This reduced our success at
> defragmenting memory on machines which use 9p heavily.
> 
> Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter)
> Cc: stable@vger.kernel.org
> Cc: David Howells <dhowells@redhat.com>
> Cc: v9fs@lists.linux.dev
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Reviewed-by: David Howells <dhowells@redhat.com>

Re: [PATCH v2 1/9] 9p: Add a migrate_folio method

[Dominique Martinet]

Matthew Wilcox (Oracle) wrote on Wed, Apr 02, 2025 at 03:59:55PM +0100:
> The migration code used to be able to migrate dirty 9p folios by writing
> them back using writepage.  When the writepage method was removed,
> we neglected to add a migrate_folio method, which means that dirty 9p
> folios have been unmovable ever since.  This reduced our success at
> defragmenting memory on machines which use 9p heavily.
> 
> Fixes: 80105ed2fd27 (9p: Use netfslib read/write_iter)
> Cc: stable@vger.kernel.org
> Cc: David Howells <dhowells@redhat.com>
> Cc: v9fs@lists.linux.dev
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Given I'm not in Cc of the whole series I'm lacking context but I assume
that means I'm not supposed to take this in.

I won't pretend I understand folios anyway, but commit messages makes
sense to me:
Acked-by: Dominique Martinet <asmadeus@codewreck.org>

Thanks,
-- 
Dominique Martinet | Asmadeus

Re: [PATCH v2 1/9] 9p: Add a migrate_folio method

[Matthew Wilcox]

On Thu, Apr 03, 2025 at 12:46:17PM +0900, Dominique Martinet wrote:
> Matthew Wilcox (Oracle) wrote on Wed, Apr 02, 2025 at 03:59:55PM +0100:
> > The migration code used to be able to migrate dirty 9p folios by writing
> > them back using writepage.  When the writepage method was removed,
> > we neglected to add a migrate_folio method, which means that dirty 9p
> > folios have been unmovable ever since.  This reduced our success at
> > defragmenting memory on machines which use 9p heavily.
> 
> Given I'm not in Cc of the whole series I'm lacking context but I assume
> that means I'm not supposed to take this in.

Right; I'm routing this whole series via Christian.  There's various
bits of the VFS that need to be touched as part of this series, and
it'd take forever to get it all merged by going through individual
maintainer trees.

> I won't pretend I understand folios anyway, but commit messages makes
> sense to me:
> Acked-by: Dominique Martinet <asmadeus@codewreck.org>

Thanks!  Folios aren't really that hard a concept for a filesystem
developer to understand, but dhowells has done a great job of insulating
you from even having to understand them with netfs.  All they are is
a container of one-or-more pages which maintain all the filesystem
state which used to be managed per-page.  eg dirty, writeback, locked,
offset-in-file, number-of-mappings.

There's more to it from a MM point of view, but as a filesystem
developer, that's all you really need to understand.