Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2025-01-14 at 10:40 +0100, Miklos Szeredi wrote:
> On Tue, 14 Jan 2025 at 09:38, Miklos Szeredi <miklos@szeredi.hu> wrote:
> 
> > Maybe an explicit callback from the migration code to the filesystem
> > would work. I.e. move the complexity of dealing with migration for
> > problematic filesystems (netfs/fuse) to the filesystem itself.  I'm
> > not sure how this would actually look, as I'm unfamiliar with the
> > details of page migration, but I guess it shouldn't be too difficult
> > to implement for fuse at least.
> 
> Thinking a bit...
> 
> 1) reading pages
> 
> Pages are allocated (PG_locked set, PG_uptodate cleared) and passed to
> ->readpages(), which may make the pages uptodate asynchronously.  If a
> page is unlocked but not set uptodate, then caller is supposed to
> retry the reading, at least that's how I interpret
> filemap_get_pages().   This means that it's fine to migrate the page
> before it's actually filled with data, since the caller will retry.
> 
> It also means that it would be sufficient to allocate the page itself
> just before filling it in, if there was a mechanism to keep track of
> these "not yet filled" pages.  But that probably off topic.
> 

Sounds plausible.

> 2) writing pages
> 
> When the page isn't actually being copied, the writeback could be
> cancelled and the page redirtied.  At which point it's fine to migrate
> it.  The problem is with pages that are spliced from /dev/fuse and
> control over when it's being accessed is lost.  Note: this is not
> actually done right now on cached pages, since writeback always copies
> to temp pages.  So we can continue to do that when doing a splice and
> not risk any performance regressions.
> 

Can we just cancel and redirty the page like that when doing a
WB_SYNC_ALL flush? I think we'd need to ensure that it gets a new
writeback attempt as soon as the migration is done if that's in
progress, no?

-- 
Jeff Layton <jlayton@kernel.org>