On 1/14/25 10:40, Miklos Szeredi wrote: > On Tue, 14 Jan 2025 at 09:38, Miklos Szeredi <miklos@xxxxxxxxxx> 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. With /dev/fuse buffer copies should be easy - just allocate the page on buffer copy, control is in libfuse. With splice you really need a page state. > > 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. > I wrote this before already - what is the advantage of a tmp page copy over /dev/fuse buffer copy? I.e. I wonder if we need splice at all here. Thanks, Bernd
