All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zi Yan" <ziy@nvidia.com>
To: "Matthew Wilcox" <willy@infradead.org>
Cc: <linux-fsdevel@vger.kernel.org>,
	"David Hildenbrand" <david@redhat.com>,
	"Joanne Koong" <joannelkoong@gmail.com>, <linux-mm@kvack.org>,
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 06/11] migrate: Remove call to ->writepage
Date: Thu, 27 Mar 2025 13:22:38 -0400	[thread overview]
Message-ID: <D8R80OMV06HN.2MXFKF6L5851V@nvidia.com> (raw)
In-Reply-To: <Z-WCMYYQRsrRlikA@casper.infradead.org>

On Thu Mar 27, 2025 at 12:52 PM EDT, Matthew Wilcox wrote:
> On Thu, Mar 27, 2025 at 11:04:57AM -0400, Zi Yan wrote:
>> On Fri Mar 7, 2025 at 8:54 AM EST, Matthew Wilcox (Oracle) wrote:
>> > The writepage callback is going away; filesystems must implement
>> > migrate_folio or else dirty folios will not be migratable.
>> 
>> What is the impact of this? Are there any filesystem that has
>> a_ops->writepage() without migrate_folio()? I wonder if it could make
>> the un-migratable problem worse[1] when such FS exists.
>
> As Christoph and I have been going through filesystems removing their
> ->writepage operations, we've been careful to add ->migrate_folio
> callbacks at the same time.  But we haven't fixed any out-of-tree
> filesystems, and we can't fix the filesystems which will be written in
> the future.
>
> So maybe what we should do is WARN_ON_ONCE() for filesystems which
> have a ->writepages, but do not have a ->migrate_folio()?

Sounds good to me. Oh, ->writepage is removed and there is still
->writepages. Presumably, it is possible to use ->writepages in place of
->writepage in the removed writeout(), but that is meaningless since
->migrate_folio should be used.

>
>> >  static int fallback_migrate_folio(struct address_space *mapping,
>> >  		struct folio *dst, struct folio *src, enum migrate_mode mode)
>> >  {
>> > -	if (folio_test_dirty(src)) {
>> > -		/* Only writeback folios in full synchronous migration */
>> > -		switch (mode) {
>> > -		case MIGRATE_SYNC:
>> > -			break;
>> > -		default:
>> > -			return -EBUSY;
>> > -		}
>> > -		return writeout(mapping, src);
>> > -	}
>> 
>> Now fallback_migrate_folio() no longer writes out page for FS, so it is
>> the responsibilty of migrate_folio()?
>
> ->migrate_folio() doesn't need to write out the page.  It can migrate
> dirty folios (just not folios currently under writeback, obviously)

Got it. And I just noticed that Joanne's change is in
migrate_folio_unmap() for folios under writeback and irrelevant to this
change.

-- 
Best Regards,
Yan, Zi


  reply	other threads:[~2025-03-28 13:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 13:54 [PATCH 00/11] Remove aops->writepage Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 01/11] f2fs: Remove check for ->writepage Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 02/11] f2fs: Remove f2fs_write_data_page() Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 03/11] f2fs: Remove f2fs_write_meta_page() Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 04/11] f2fs: Remove f2fs_write_node_page() Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 05/11] vboxsf: Convert to writepages Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 06/11] migrate: Remove call to ->writepage Matthew Wilcox (Oracle)
2025-03-27 15:04   ` Zi Yan
2025-03-27 16:52     ` Matthew Wilcox
2025-03-27 17:22       ` Zi Yan [this message]
2025-04-01 13:32         ` David Hildenbrand
2025-03-07 13:54 ` [PATCH 07/11] writeback: Remove writeback_use_writepage() Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 08/11] shmem: Add shmem_writeout() Matthew Wilcox (Oracle)
2025-03-08  5:31   ` Baolin Wang
2025-03-07 13:54 ` [PATCH 09/11] i915: Use writeback_iter() Matthew Wilcox (Oracle)
2025-03-07 13:54 ` [PATCH 10/11] mm: Remove swap_writepage() and shmem_writepage() Matthew Wilcox (Oracle)
2025-03-08  5:34   ` Baolin Wang
2025-03-07 13:54 ` [PATCH 11/11] fs: Remove aops->writepage Matthew Wilcox (Oracle)
2025-03-17  1:08   ` Fan Ni
2025-03-17  3:22     ` Matthew Wilcox
2025-03-17 22:30       ` Matthew Wilcox
2025-03-18  8:10         ` Thomas Hellström
2025-04-01 16:26           ` Matthew Wilcox
2025-05-02 14:33             ` Thomas Hellström
2025-03-07 15:45 ` ✗ Fi.CI.BUILD: failure for " Patchwork
2025-03-28  9:40 ` [PATCH 00/11] " Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D8R80OMV06HN.2MXFKF6L5851V@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=david@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joannelkoong@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.